Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1] 2 3 ... 10
 on: August 06, 2020, 05:03:01 am 
Started by Reuben B. - Last post by Reuben B.
If you look at your typical PC keyboard, you may see that there are two keys with “Enter” written on them.   

If you look in FGLDIR/lib/default.4ad, (the default action defaults file if none other is specified), the entry for the “accept” action you will see two accelerators, the acceleratorName attribute with a value of “Return”, and the acceleratorName2 attribute with a value of “Enter”.  This entry is mapping the two different “Enter” keys to trigger the “accept” action.

What key is the “Return” accelerator?, what key is the "Enter accelerator?, and how can you map the “Enter" in the numeric keypad to the “nextfield" instead of the “accept” action?


 on: August 04, 2020, 11:57:11 am 
Started by Olivier E. - Last post by Olivier E.
Dear Customers,

     The Support Request upgrade succeeded. You can work normally!  :)

Thank you for your patience,

Olivier - Four Js Support

 on: August 04, 2020, 09:37:09 am 
Started by Olivier E. - Last post by Olivier E.
Dear customer,

We started the maintenance of the support portal till 12:00pm.

When the maintenance is finished we will send a new post.

Sorry for the inconvenience,

Olivier - Four Js

 on: August 03, 2020, 04:56:43 pm 
Started by Olivier E. - Last post by Olivier E.

 Genero GAS 3.20 and GMA 1.40 Maintenance Release

Four Js is pleased to announce a Maintenance Release of Genero Application Server 3.20.12 and Genero Mobile for Android 1.40.10.

GAS 3.20.12 includes the following fixes :

GMA 1.40.10 includes the following fixes :

Using GMA 1.40.10 with GST 3.20 requires Google Android SDK command-line tools. Google changed its directory structure. Please read the points 6 and 7 of the following documentation page:

These versions are now downloadable from the website :

Note : All Four Js Genero customers under maintenance have free access to the new release.

Best regards,

Four Js Development Tools

 on: August 03, 2020, 11:52:06 am 
Started by Olivier E. - Last post by Olivier E.

 Fours Js support request server under maintenance

Dear Customers,

The Fours Js support request server is planned to be under maintenance on Tuesday, August 4th 2020 from 09:30am till around 12:00pm (GMT+2).

To raise a support request with the European support team (For UK customers, please see below) during this maintenance period,  please send email to or call +33 3 88 18 61 24.

To raise a support request with the UK support team during this maintenance period, please send email to or call +44 (0) 370 111 5147.

To raise a support request with the Australian support team during this maintenance period, please send email to or call +612-8004-5890.

We apologize for any inconvenience caused.

Best regards,

Four Js Support team

 on: July 30, 2020, 05:10:46 am 
Started by Reuben B. - Last post by Reuben B.
To understand why your right justified field labels may not right align as intended, it is first necessary to have an understanding of …

   • fonts, and the concept of monospaced fonts, and proportional fonts.
   • how field labels inside a .per are compiled as a LABEL widget with a posX and gridWidth property.

A font has the property that it is either monospaced or proportional.  A monospaced font has the property that each character takes up the same amount of space.  A proportional font has the property that each character will take up a different amount of space.  Typically i is the narrowest, whilst M or W are the widest.

When compiling raw text inside a Genero form, a LABEL is created that has a posX and gridWidth property.  If a proportional font is used, then two words with the same posX and gridWidth values are not guaranteed to end in the same position.  As a result whilst the developer might have intended this raw text to right align, there is no guarantee that they will.

The solution is to explicitly define a LABEL and use the JUSTIFY=RIGHT property.  Explicitly defining a LABEL also has other advantages.


 on: July 24, 2020, 05:57:37 am 
Started by Reuben B. - Last post by Reuben B.
FGL_WINMESSAGE and FGL_WINQUESTION are not built-into the runtime system, but are examples of utility functions that we provide.  As such if you look in $FGLDIR/src/fgldialog.4gl you will find that these functions are implemented by 4gl code and are compiled into $FGLDIR/lib/fgldialog.42m

This means that if you are not happy with these utility functions, you can look at the source and use these as inspiration to write your own library functions.


 on: July 24, 2020, 05:54:09 am 
Started by Reuben B. - Last post by Reuben B.
The FOLDER and PAGE containers combine to show the contents of one particular PAGE.  The user can then click on the Page Header to show another particular PAGE.

The key property of a FOLDER and PAGE is that only one PAGE is ever shown at a time, the user is expected to click on the page header or tab to show another page.

The questions we get asked relate to how to control what particular folder page is shown?

The answer to that question is that the front-end will display the Folder Page that contains the field with the focus.  If you programmatically want to change the page shown, do a NEXT FIELD to a field on the page you want to show so that it has the focus, or if you have a singular dialog on each page, in your 4gl switch to that dialog (by implication the field with focus will now be on the desired page)

However there are situations where the dialog might not have a field with focus e.g. MENU, or the field with focus might be outside of the FOLDER.   A method available is to use the ui.Form.ensureElementVisible method to ensure that the page is visible.


 on: July 22, 2020, 09:01:15 am 
Started by Benjamin G. - Last post by Benjamin G.
Hello Sebastien, Reuben

Today we have accustomed users to opening dozens of "pages" in "browsers".
I'm not sure it's a good way to work, but it's a reality.
A user wants to be able to open, for example, two "item code" to compare the differences ...

I understand that "forking" is not necessarily a solution and certainly too specific to UNIX.

The WebService solution is indeed an "elegant" solution but which has a high cost in terms of development and maintenance.
I reserve the WS when the data must undergo a pre-processing before being consumed.

There are other "problems" in not making a "monolithic" application this is the number of processes that must be managed on the server. Example, if I have 500
users and each opens say 6 "main programs" (item management, customer management, phone order entry, FAX order entry, order viewing, statistics, ...)
this already gives me 3000 processes in addition to all the other processes.

When i need to do server or DBA maintenance this high number of "processes" quickly becomes a "headache".

We use internally infomix 4gl  with "monolithic" and "multiple-main" models, but without the possibility of opening several at the same time.

The first is "very good" because the system resources are easy to control, the second is also "light" and only has the default of doing a lot of CONNECT / DISCONNECT. But these two models are "old fashion" and our users needs 2 or more logins so they can launch multiple instances of the same application. Example, a vendor needs a login to process an order entry by phone, an order one for a FAX order and an other one for "maitenance or statistics" purpose ...

This is why the concept of "parallel dialog", although we may not have understood the concept, seemed to us an excellent compromise. According to our tests the only thing that would have to be added to make it work
in order to have a "monolithic" application with "calls" is an "event" which could be triggered when
the user "activates" the dialog. This would be possible if at the moment the "windows" window changes to "foreground".
In other words, in the "active dialog" have an "ON ACTIVATE" event with in parameter the name of the dialog which returns in foreground in order to be able to
connect to the "dialog" of the window that has been chosen by the user.


 on: July 22, 2020, 01:03:19 am 
Started by Benjamin G. - Last post by Reuben B.

In the first case we have a "monolithic" application with one main and a lot of functions, this design allows to have a single DB connection and to be able to share variables between programs but does not allow having several "dialogs" open in parallel which for the user is frustrating because he has to close one "dialog" to open another.

We did some tests with the "parallel dialogs" but without success.

In the second case, an application split into a multitude of "main" we gain user flexibility, it can have several dialogs in parallel, but
to the detriment of a high number of DB connections and no "direct" data sharing between the different "main". Another idea might be to be able to launch a main module not as an independent process but as a "fork" of the "main menu" this would allow to have a single connection to the DB (at least with Informix, feature is supported) and to be able to share data.


I would've said that the overwhelming majority of the code I see follows the second case.  At any given point a single user may have multiple Genero programs running, each program having its own private variables and each program having its own database connections.  I can't remember when I last saw your first "monolithic" case.

A typical scenario might be that a store worker might be running
"Main Menu" - program they launch at the beginning of the day from which they launch other programs"
"Sales Entry" - a program to enter new sales
"Debtor Enquiry" -a program they can use to check debtor balances, either launched from Main Menu or from Sales Entry passing a debtor code as an argument
"Stock Enquiry" - a program they use to check stock balances, either launched from Main Menu or from Sales Entry passing a product code as an argument

so this would be 4 seperate database connections, quite possibly 4 copies of the same prepared or declared database cursor, and 4 instances of the same variables e.g. username

Over the course of the day, user might start a few more programs
"Transfer Entry" - to transfer some stock in
"Purchases Entry" - to order some stock
"Customer Maintenance" - to update customer details
etc etc

and I guess the scenario you are worried with this model is by the end of the day, user has all these program open sitting idle but consuming a database connection.

You can be smart about your database connections.  As Seb said for case of Main Menu, once the menu is loaded, do you still need the database connection?

Similarly for each program, by design encourage the user to exit the program when they have finished rather than perhaps going to a point ready to enter a new transaction and waiting, so that you don't get lots of programs sitting idle.  Use ON IDLE to exit the program etc.

This has reminded me of an early Genero transformation where the database started to slow down.  This was because the  customer had taken the opportunity to tidy up the code so that database cursors were used rather than static SQL statements preparing the same database operation multiple times.  However this resulted in hundreds of Point of Sale terminals throughout the country sitting at an INPUT login, password consuming database memory whilst waiting for the next store worker to come along and process a sale.  The solution was to make sure FREE, CLOSE were used to free up resources when program got to this point, that is did we want to hold onto these resources for  minutes to save a second or two?  15 years later, I probably also would suggest now using Web Services as a solution so ...

as Seb suggested, you might want to consider a multi-tier solution, add to your tests a third case ' an application split into a multitude of "main" we gain user flexibility,' like you had, but code it so that each application has no database connection but any database activity is done via a Web Service call.  I could see this being advantageous in a store or branch situation where you have many instances of the same program, a limited number of SQL statements executed multiple times, and so instead of having 100's, and 1000's of these programs each with their own database connection, and copies of the same database cursor, you end up with a pool (probably numbering in single digits) of web service programs running that have the database connection and cursor in memory.  You are then looking at the numbers to measure if the extra overhead in the web service call is worth it in terms of what you save in database resources.



Pages: [1] 2 3 ... 10
Powered by SMF 1.1.21 | SMF © 2015, Simple Machines