next »

[Stephen T.]

Good morning.

I have just started to use Studio and the report writer, and want some help on importing my existing projects.

Currently I have a structure of:

/base-location/'project'/type-of-module/release-environment

...where project may be developments for a particular customer or an internal software system, the type-of-module then splits the 'programs' and functions (ie maintenances, reports, 'production' modules) and release-environment is development, test or released.

Each set of modules sharing a release environment also share a database schema.

So if I have a module called 'loadSales' that load sales in a retail project, I would then have a structure such as:

/base-location/retail/production/dev/loadSales.4gl

...that same module could then also exist in both the test and 'released' environments - ie  the module could then appear as:
 
/base-location/retail/prod/[test|rel]/loadSales.4gl

The loadSales modukle may then be dependent on a set of libraries in 'funcs' (functions):

/base-location/retail/funcs/[dev|test|rel]/ext_calcCost.4gl

...and also a set of globals defined in the 'templates' directory:

/base-location/retail/templates/[dev|test|rel]/base_globals.4gl

All of those modules then share the 'release-environment'_retail schema located under the 'production' directory (prod):
/base-location/retail/prod/[dev|test|rel]/'[dev|test|rel]_retail.sch

Also, the forms for each 'module' reside with that module and are named by the module - ie if loadSales had two forms, they would reside in the prod directory and be called 'loadSales1.per' and 'loadSales2.per'.


The import of the project works fine and creates the virtual project in the workspace. The forms in the directories seem to get hived off into their own [dev|test|rel]' sub library (ie I get /base_location/retail/prod/dev/dev/...forms... ). The modules with 'main' get splitinto theiir own 'applications' - again fine.

What I then wants to do is to make the dependency links - ie I want all the 'applications' in 'prod'/'dev' to be linked to all the library modules in 'funcs'/'dev' and to the templates in 'templates'/'dev' as well as being linked to the 'dev'_retail schema.
The same applies to the 'test' and 'rel' release environments.

So after all that diatribe, from what I can see, I can set the dependencies for the external functions and forms quite easily as I can set the dependency at the directory level (ie the library level), but I can't see a quick way to group all the 'applications' and apply the same dependencies for all of them at the same time. Is the only way to set the dependencies 'application by application'?

[Stephen T.]

Apologies - forgot to specify the version:

Genero Studio
Version 2.32.24 build-101641
Target lnxlc23

[Olivier E.]

Hello Stephen,


Each customer has his own way to manage project before using Genero Studio. Therefore difficult to create a generic tool.


But you are going to create your project the first time, and work with it a very long time. :)



PS: your post is a support issue not a Forum one. May I ask you to contact your support center please ?


Olivier ECKERT - Four Js

[Stephen T.]

Olivier,
Sorry, I never quite understood what was a 'support' issue as opposed to a forum issue.

As an secondary thing (and this also maybe support - I'm not sure) - when you 'build' the default target directory appears to be set to the 'workspace'/bin directory. Again, I know we all probably have separate 'pre Studio' environment layouts, but would it be possible/sensible when importing a project for it to detect where the compiled objects are and to default the target for that directory to that directory (or at least offer that as an option)? IE 'in my case' the source and object reside in the same directory, so the lib 'funcs' would compile to funcs. Or are you trying to enforce a 'best practice' by compiling to 'bin'? (In my case I already have  bin directories in each project that contain scripts etc)

[Reuben B.]

Olivier,
...
As an secondary thing (and this also maybe support - I'm not sure) - when you 'build' the default target directory appears to be set to the 'workspace'/bin directory. Again, I know we all probably have separate 'pre Studio' environment layouts, but would it be possible/sensible when importing a project for it to detect where the compiled objects are and to default the target for that directory to that directory (or at least offer that as an option)? IE 'in my case' the source and object reside in the same directory, so the
If you don't want to edit this property every time you open a new project, unforunately you can't change it in Preferences.  However have a look in GSTDIR/bin/src/studio/tpl.  You will see a file template.4pw.  Also have a look in GSTDIR/conf/creatables.conf and search for template.4pw. 

 lib 'funcs' would compile to funcs. Or are you trying to enforce a 'best practice' by compiling to 'bin'? (In my case I already have  bin directories in each project that contain scripts etc)

Stephen,

There has been plenty of internal debate over that setting.  Personally I am of the view that as fglcomp/fglform place by default the compiled objects in the current directory  then Genero Studio should do the same by default but haven't been able to convince the Studio developers otherwise. 

It is easy to change though. 

If you open a New Project, click on the Project Node and inspect its properties, you will see a property "Target directory" that has a value of $(WorkspaceDir)/bin.  You just need to change that to $(WorkspaceDir). 

If you are importing the project, there should be a checkbox in the dialog, "Define the source directory as target directory", and so when you import the project this will be done for you.

Finally if you don't want to make this change everytime you create a new project, whilst not formally recommended, have a look in GSTDIR/conf/creatables.conf, and search for template.4pw.  Then look in GSTDIR/bin/src/studio/tpl and notice the files in that directory.  You can probably put two and two together, and figure out what Studio does when you go File->New, and so customize it such that when you open a new project, Target directory is set to the appropriate directory.

Hope that helps,

Reuben

[Reuben B.]

Olivier,
Sorry, I never quite understood what was a 'support' issue as opposed to a forum issue.

...

If you were in my region I would have answered your question and then suggested you try the forum to see what other people around the world are doing.  In support centres we only hear about where people get stuck, and not their successes so it is quite possible someone may have had the same issue and the forum is the appropriate space for them to pass on their success story.

With your original issue, I'll just point out that .4pw are xml files.  So not only is it possible to view/edit them in a text editor, it is possible for you to write a small 4gl program using the om or xml classess to amend a .4pw (ie add nodes or add attributes), or create a new .4pw.  If you have consistent makefiles, or a good data dictionary, that maybe a feasible way for you to create your original .4pw's.

Reuben

[Stephen T.]

Reuben,
Thanks for the help - really appreciated.

I  miss the old forum format, where you could see what was going on in general - and what people found good/bad/indifferent re the various facilities/features. Now, I'm not sure which features are in common use, how they're being used etc as whatever is deemed an issue here is pointed at support and then 'vanishes' - so you never see the outcome - let alone the issues that are now directly reported to support without even appearing here at all. C'est la vie I suppose.

I also mentioned to Neil M in the UK that if you try to change the 'targetdir' linked to each node in the project, you can't simply change it to $(InputDir) either - as it assumes that you are talking relative to the Workspace and appends InputDir to the Workspace. So it appears you have to change the targetDir to the specific ($(WorkspaceDir)/blah/blah...) rather than simply $(InputDir).

Anyway, I've modified the first project ok, so it now 'builds' basically as it used to without Studio. It wasn't a large project - so didn't take too long anyway. The longest bit was setting the dependencies on the applications - the libraries were fine as they were done at the 'directory' level.
I know seem to have a Studio 'project' that builds as the old environment -  meaning I can use the old and new environments interchangeably - which is what I was hoping to achieve for the initial tests. Next is getting the project modules to run!

Thanks again.

Steve