Hi all,
Our projects are configured so that the project includes only modified code from the base product. In the propath definition the project is first and the base product is second. Sometimes we would like to open a file from the base product to see if we needed to copy that to the project and modify it (or just to see what is in it). CTRL+Shift+R works for only files in the project but not in the propath.
Is there a way to open files only in a propath, too?
Also a relating question: is it possible to define the resource search (CTRL+Shift+R) by giving a part of the whole file path? Eg. if I wanted to search only those files that are in folder example (there can be multiple example folders in different paths) and named prog.p I would write example/prog.p; thus I wan't to find all prog.p-files whose parent directory is example. I can't get this working - it seems to work only with file names; thus prog.p finds the right file but also hundreds of others files with same name in different folders.
Is there some kind of setting to adjust this functionality to search in only files in given (parent) directory ?
-Teemu
Why not add a second project to the workspace pointing to the base product?
No. There is no possibility to open the file from PROPATH unless it is part of workspace.
Why don’t you import the base code as other project if this is needed?
That seems to be a reasonable way to do it. Thank you for your answer!
How about this other part of the question:
is it possible to define the resource search (CTRL+Shift+R) by giving a part of the whole file path?
> How about this other part of the question:
is it possible to define the resource search (CTRLShiftR) by giving a part of the whole file path?
Sorry, don't know a solution for that. The Ressource search supports matches (*), CamelCasedSearch (CCS would find the previous term) and begins.
The File Search Dialog allows to limit the search by folder, project or working set. Don't know if that works for you.
Teemu, look at http://www.oehive.org/project/KsvPlugin. This plugin for OEA does precisely that what you want, namely, opens a file in a propath. Apart from that it can do other things which you might find useful.
HTH
Thank you Sergey!
Hi Sergey,
I am trying this in 10.2B but when I click on Open File in PROPATH nothing happens.
I don't want to criticize the fact that this plugin is available at all!
But what advantage do people see in being able to open a file in OpenEdge Architect that's not part of any project?
For me one of the biggest charms of the project based IDE is that every file is part of the workspace and a contained project. Any kind of reference to files outside the workspace scares me!
For me one of the biggest charms of the project based IDE is that
every file is part of the workspace and a contained project. Any kind
of reference to files outside the workspace scares me!
I concur with this.
I'm curious: assuming a new module/product or a product/application refactored into OEA projects, what are the reasons to have anything in the project's propath other than $ and the $ from other projects in the workspace on which a project dependends? (you can tell I like the one-workspace-one-product way of working).
I realise that there are cases where the application is simply pulled in to OEA as-is and so the code paths haven't been simplififed. There is also the case where the module/app depends on a 3rd-party module/app.
-- peter
In our case we are modernizing an application. That applciation contains legacy GUI code as we redevelop stuff in OpenEdge GUI for .NET.
The GUI code is maintained in the AppBuilder and version control for that code is in cvs.
The .NET code is maintained in OEA and version control for that code is in svn.
Sometimes we want to inspect GUI code from the OEA environment so it seems very useful to be able to open that read-only in OEA.
After inspection we sometimes decide to override that code in our .NET environment, so it seems very useful to be able to 'promote' that code into our .NET project.
It seems the ksv tools offer these capabilities so I wanted to look into that.
Makes sense?
Hi Peter!
Unfortunately the plugin works with 10.2A only. I have plans to move it on 10.2B though. I'll let you know as soon as it's ready
Makes sense?
Yes (in your case it looks like that and no ). I know these situations and with 10.2B I usually organize them as two projects (using a shared AVM). First it's absolutely possible to use two different team providers for those two projects to do the fresh start with svn without losing all the history information in cvs.
When I work with AppBuilder code, I also load that into a project in OpenEdge Architect. Rather than using the embedded AppBuilder, I start a separate AppBuilder session and I very often drag and drop files from the Eclipse Resources View to the AppBuilder to open the files for Visual Editing (my favorite method here).
For code editing and interacting with the SCM tool, I still use OpenEdge Architect.
And I guess I'd do the same in your situation, Peter.
In our case we are modernizing an application. That applciation
contains legacy GUI code as we redevelop stuff in OpenEdge GUI for
.NET.
Makes sense?
>
Absolutely.
It is possible to open external files in OEA via File>"Open File...", but that's really not efficient unless you know the full path.
And there's Mike's much better suggestion too.
-- peter