Can you customize the PROPATH of an RTB Plugin project?

Hi.

Roundtable sets the plug-in PROPATH based upon what you have defined for the Roundtable Workspace path. You can change the PROPATH for the project, but Roundtable will put it back when a task is selected. However, for a launch/run configuration, I wouldn't think that you would want to change your project PROPATH at all. The launch configuration can have it's own PROPATH and application-specific settings.

How do you update the PROPATH in the Launch Configuration? I need the r-code to be after the Active Task entries but before the RoundTable folders.

Note that I want to keep the project's default PROPATH to get the Active Task entries automatically.

Hi.

Once you launch an application, it creates a run configuration. Switch to the OE perspective, and choose Run > Run Configurations from the main menu. Select (or create) your run configuration. You should see a ProPath tab where you can set it as you need to launch your app.

It's not that simple. RTB Task seems to compile code in the same location as the code. Our production code which RoundTable points to has an r-code folder (and several other folders) that the RoundTable plugin is not including to the auto-generated PROPATH.

This r-code folder needs to go after the Task entries, but should be above the source code folders.

NOTE: You cannot rearrange the default PROPATH inside the Launch Configuration window. The move buttons are disabled..

You can change the PROPATH of a launch configuration to whatever you wish for it to be. You may not can move the entries of the specified project up/down, but you can add new entries as needed. Generally for testing task level share, the PROAPTH order would be <task>,<workspace>,<default>.

I need the r-code between <Task> and <Workspace> because;

1. We have a separate r-code location, so it should be <Task><Workspace r-code><Workspace>.  You can only add above or below the RoundTable default PROPATH.

2. Class files (specially those CLS files that are being called from another CLS) will no longer run uncompiled. You will get unknown datatype error when the r-code of a CLS is not found.

3. The application will be too slow if it has to recompile code on the fly.

4. [DESIGN TIME ISSUE] The Visual Designer will not always load a form in Design View that uses ABL controls or usercontrols if the ABL controls and usercontrols are not compiled.

Hi.

I am not suggesting that you have to compile on the fly but maybe we are speaking of two different things (or maybe there are two different issues).

I assume that you have specified r-code directories for your Workspace Module definitions and you need those in your PROPATH for your testing run configuration, correct?

I need the r-code for both design-time and run-time. CLS files will not load in design view without all the r-codes of the classes that a CLS dependent on. I need the r-code during run-time to avoid unknown datatype error.

Yes, we have an r-code folder in our Workspace Module definitions.

To modify the PROPATH during design-time, you (or your admin) need to change the Roundtable Workspace path to include the additional path entries that you require.

That sounds promising.

But before we go changing our age-old configuration, my co-worker just found a more straight forward way of managing check out location while still having the flexibility of the regular OpenEdge Project. I'm going to give the Roundtable Task Group - regular OpenEdge Project combo a try.

Roundtable's Task Group allows you to specify a custom checkout location which I can just point to my regular OpenEdge project folder. More steps to create a workable Task, but it simplifies a lot of things, for example, I just need to maintain my Launch Configuration once.    

Yes but I don't believe this solves the issue with needing compiled cls files during design time.

I don't think that you have to involve Task Groups for this situation. Task Groups are good for sharing your changes with your team without affecting the central-share Objects/configuration.

For fun, I created a standard OpenEdge project and looked at the PROPATH entries. The PROPATH does not include the 'rcode' directory (when a separate r-code destination is chosen) either.

In standalone Roundtable, you can specify the Task folder. The plugin won't, but the Task Group seems to give the same behavior.

Yes, the initial PROPATH of a regular OpenEdge project will not include the r-code, but it will allow me to customize the PROPATH to any configuration I like (I have my check out location first then the Central r-code then Central source code). And I only need to set the PROPATH up once as long as I can check out programs to same location regardless of which Task I'm working on.

If you change the Roundtable Workspace path, you should get the same results. But since a standard OE project doesn't include the rcode directory, I wonder if it is necessary the separate rcode paths.

For standard OE project, you will need to build the PROPATH to make it useful. That's a given.

With regards to the need for the rcode;

- You need the rcode (of other CLS files) to open a CLS files (ex. form with custom controls) in design view.

- You need the rcode to be able to run your program without getting the unknown datatype error. This is probably related to the first one.

Granted the issues might just be limitations of OpenEdge, but to workaround these issues require a better control over the PROPATH entries.

I'm not sure it's a given. When I don't modify it (the PROPATH) at all, it works as expected with finding the proper resources.

You can control the PROPATH by changing the Roundtable Workspace path entries.

If we update the Roundtable Workspace path entries, will the compile when in Task status also send the rcode to a designated folder?

I answered that in the other thread yesterday.

My other thread was regarding code in Central status. So I assume the same is true when in Task status.

Yes, correct. We are issuing a COMPILE command to the OE project with the SAVE INTO option. Unfortunately, the SAVE INTO option does not create the structure. We have logged this and have made a change to our plug-in to touch the appropriate structure into existence if it does not exist.

OK good, I'll ask our DB manager to make some changes to the Workspace path.

[quote user="Jeff Ledbetter"]

Yes, correct. We are issuing a COMPILE command to the OE project with the SAVE INTO option. Unfortunately, the SAVE INTO option does not create the structure. We have logged this and have made a change to our plug-in to touch the appropriate structure into existence if it does not exist.[/quote]

SAVE-INTO only requires the top-level directory to exist, the lower directory structure is created automatically.

For class files, yes. Not for all compilable files.

Sorry, you are correct... that would explain this line above our compiler. :-)

            RUN CreateSubDir ( cTargetDir ).

            COMPILE VALUE( cProgramFull )
               LANGUAGES( VALUE( IF CONNECTED( "translat":U ) THEN "en-US:en,nl,nl-BE:nl,fr,de,es,it,pt":U ELSE ? ) )
               SAVE INTO VALUE( cTargetDir )
               MIN-SIZE       =  TRUE
               GENERATE-MD5   =  TRUE
            NO-ERROR.

Bad news, adding the r-code folder above the source folders caused the standalone Roundtable to stop working properly. It looked like Roundtable was trying to find the program source code under the r-code folder.

I did not continue verifying the Rountable plugin because of the above issue.

We created a Roundtable enhancement request to be able to specify r-code folder in the PROPATH.

Thanks,

I do not see the same issues that you are seeing with Visual Designer.

Do you have rcodes? If you do, removed them and turn off any setting that will auto-rebuild your programs. Also, many of our CLS programs have 2 to 3 level of CLS program dependency.

Ex.

Form.cls

 -> UserControl.cls

      -> UserControls.cls

           -> Control.cls

      -> Control.cls

Please add any additional information to the support case you created instead of on the forum.  Thanks. Maybe send some screenshots to help demonstrate what you are seeing.

Ok, I know what you are seeing - I duped it. Your class cache is set to Workspace. If you set it to PROPATH, your references will all resolve just fine.  I have reported this to our tech support as well.