Four Js Customer Forum

This OPEN WINDOW nice_window AT rows,columns WITH FORM "FORM/form1" is/was a typical function of ours in 4JS.

Can you give us some advice, how to eliminate the problem with setting fixed position of the window, while converting 4JS to GENERO. The problem is, that until now, we opened windows on a certain position and now this position is given by system, what makes us significant problems in many program parts (design problems naturally).

At the same time, we would like to ask whether 4JS does not plan to reimplement stated function, that would make it easier for, i believe, all of us, that are converting 4JS to Genero.

Thanks in advance

Bystrik,

You should register to the 2.20 EAP and try the "traditional" mode we have introduced in that version.

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/NewFeatures.html#traditional_ui_mode
https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/MigI4GL.html#easy_ui_migration
https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/DynamicUI.html#TRADITIONAL_MODE

Seb

- Seb answered faster than me ;) here's my answer anyway -

You're definitely a good candidate for Genero 2.20 EAP.

One of the "new" features of 2.20 is what we called "Traditional mode" (or "compat mode"):

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/NewFeatures.html#traditional_ui_mode

and

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/DynamicUI.html#TRADITIONAL_MODE

When using this mode, GDC tries to mimic BDS behavior:
- Fixed size grid
- fixed font
- OPEN WINDOW AT, DISPLAY AT, OPTIONS xxx LINE

This should also ease the migration: you can start your application with a SCREEN form, and then you would like to implement a new feature using Genero new features. So just make an OPEN WINDOW with a LAYOUT form, then this new form will be "modern".
It is expected to work in the other way, so you can start a new Genero window, and later open a traditional SCREEN with your traditional code.

The main limitation is that you can't, in the same window, mix modern and traditional forms.

I would recommend you to participate to the EAP and try how the traditional mode can help you in your migration process.


Regards,
Pierre-Nicolas

Thank you for your early reply,

we just downloaded EAP and will try it in the very near future.
We would like to ask whether also in the new environment, it would be possible to combine new features with opening window at precise position. There is quite big difference in the display of opened windows between 4JS and Genero environment.
The opened window in many cases serves as some information completing the other window and therefore should not overlay it.

Other example where we use precise position of the window is different kind of menu as you use (TopMenu). You can see such menu in the screenshot I attached. We are trying to implement and use TopMenu wherever it is possible, but there are cases where we cannot use it. These are mainly parts of programs where there are 4 and more "levels". In such case the TopMenu is not that transparent. Also most of our customers are used to open some program and the menu stays in rear – so if the were in level 4 of the menu, it stays open. If there was some similar menu in your program it would be welcome.

Maybe modified START MENU – so that it is possible to CALL functions and not just execute programs (FGLRUN xxxx) would be nice. Have you already considered such option? Anyway it would be probably transparent just to 3 levels.

I'm afraid the answer will not be a clear "yes".

The aim of the traditional mode is clearly to facilitate migration from BDS (or even legacy Informix 4GL code, if possible).
Basically: bring your old (nearly) text based application to Genero without the need of rewriting everything before.

So when running in traditional mode, you'll sill be able to make an OPEN WINDOW AT, and the newly opened window will be placed at the given position on the current window grid.
But if you start using a "modern" window, there is still no way to give a precise position where to open the window. You can rely on the different values for the styleAttribute position (center, center2, field).

This choice is due to :
- our architecture, where the same 4GL program can run with GDC, but also with GWC and text mode, on various platforms...
- history of 4GL, which is character based.

So beeing able to define a precise position for a window when your window can be opened by GDC on a large desktop, or by GWC on a PDA, where the user can change his default font size...
This is pretty easy in a character based mode with a fixed grid, but quite impossible to achieve with today's front ends.

For your specific menu problem, if you run it without the traditional flag, it won't display correctly, as the position of the windows will anyway be defined by the window manager ; more over, there is no Z-order concept, so the windows may not overlap correctly.
With the traditional flag, it should behaves correctly.

TopMenu can be a solution - it graphically does the job -, but I agree that usually topmenus have 2 or 3 levels, after that it starts to be confusing.

The startmenu modification has already been considered, but it looks like what you would like to have is our so wanted TreeView widget. I can't give a release date (we're still fighting against technical issues to integrate the tree in a classic 4GL background, and I'm not crazy enough to give a date for a feature which has been promissed for years, sorry ;) ), but I expect your tree menu to be done very easily, with classic 4GL statements.

We're working hard to have a nice solution, so stay tuned.