[Genero Enterprise 5.01 Maintenance Release :Genero BDL 5.01.03]

Genero Enterprise 5.01 Maintenance Release : Genero BDL 5.01.03

Four Js is pleased to announce a Maintenance Release of Genero BDL with Web Services (BDL – GWS - GBC - WCG - GIP) 5.01.03.

Genero BDL with Web Service (BDL - GBC - WCG - GIP) 5.01.03 is the bundle which includes:

• Business Development Language (FGL) 5.01.03
• Web service extension (GWS) 5.01.03
• Genero Browser Client (GBC) 5.01.03
• Genero Identity Provider (GIP) 5.01.03
• Web Components and wrappers (WCG)5.01.01

What's new ...

• New base.SqlHandle methods to open the SQL cursor with hold option.
• New front calls to control table column layout.
• json.Serializer class introduces a new option, allowImplicitConversion, to support implicit conversion in JSON deserialization.

You can refer to the manual for more information : https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/fgl_whatsnew_501.html.

This version also includes the following bugs fixes :

• https://4js.com/support/issue/FGL/5.01.03
• https://4js.com/support/issue/GWS/5.01.03
• https://4js.com/support/issue/GIP/5.01.03

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

Best regards,

Four Js Development Tools

Reuben,

About:

Code

MENU ... ATTRIBUTES(STYLE="dialog foo")

Providing multiple style names in the STYLE attribute of a MENU is not expected and not documented.

In fact, unlike other STYLE usages, with MENU, there is no corresponding <Style/> definition required in the .4st file!

Yes, this is confusing.

When MENU + STYLE was introduced, maybe the intention was to do something similar to OPEN WINDOW + ATTRIBUTES(STYLE="..."), but it ended up as a kind of implicit menu type without any .4st definition.

For sure, in .4st files, we have no Menu class with a menuType="modal" style attribute, similar to Window / windowType="modal".

I think we should have defined another syntax since the beginning, to define the general rendering of a MENU:

Code

MENU ... ATTRIBUTES( TYPE=MODAL )

We did it with OPEN WINDOW ... ATTRIBUTES( TYPE=... ) when we introduced splitviews for mobile.
BTW this is desupported since 4.00 (but the .4gl grammar is still there!):
https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_Migrate_to_400_paradlg_desupport.html

For consistency, I think we should have TYPE=MODAL for both MENU and OPEN WINDOW instructions, AND a STYLE attribute for style attribute indirection, so you could write:

Code

MENU ... ATTRIBUTES( TYPE=MODAL, STYLE="foo bar", ... )

+ some additional cleanup is required, to remove TYPE = POPUP/LEFT/RIGHT/NAVIGATOR from the .4gl grammar.

Seb

Hi Jeff,

Does raise an interesting issue case with regards syntax like ...

MENU ATTRIBUTES(STYLE="dialog foo")

MENU ATTRIBUTES(STYLE="popup foo")

Does the GBC code test for STYLE="dialog", STYLE="popup" when it perhaps should test for membership of a space separated list.

As to why you might have wanted a popup in a fixedfont, is it possible at some stage you were displaying two columns or accelerators.  So getting the Y and N in ...

Code

Yes    (Y)
No     (N) 

to line up, that sort of thing

Reuben

Thanks Rubin, for reminding me to go back to the basics.

We use routines to build and execute all of our popup menus, and I had failed to spot it was trying to add in 'fixedfont' to the "popup" menu style.

I'm not sure if we once had that defined as a style in our .4st or whether that was ever a thing for MENU styles, but it is not needed and all is working.

When working with GRW Reports, as per the architecture there are two inputs into the Genero Report Engine, the design of the report in the .4rp file, and the DataStream coming from in our case the 4gl program.  There is a simple mantra to remember:

- the 4gl developer gathers the data
- the 4rp designer lays out the data.
 
The 4gl program that creates the DataStream should not contain any syntax that “lays out” the data.

Read more at https://4js.com/ask-reuben/ig-267/

When creating a GDC Connection Shortcut, the first screen on the Wizard has a field “Connection Type” that is a radio-group offering 3 values.  Most Genero customers will have started out using value “Direct, connection is established via terminal emulation”, and some will have moved onto connecting to their application via GAS and so are now using “HTTP, Through a Web Server”.  There is a third value, “Local execution” which is relatively unused.

Read more at https://4js.com/ask-reuben/ig-266/

I recently saw a support case where they quoted a presentation I did at WWDC 24 regards the compatibility of two of our products.  Whilst that is flattering, for the definitive statement on compatibility the official definition is what we have documented in our documentation.

Read more at https://4js.com/ask-reuben/ig-265/

The default rendering of the Genero User Interface is that Native widgets are used on mobile devices.  This enhancement dates back to 2018 and the 1.00.47 release of the Genero Browser Client, you can see this mentioned in the GBC 1.00.47 New Releases and Upgrade Notes.  The result of this is that on a mobile device, instead of getting the Four Js DATEEDIT, DATETIMEEDIT, TIMEEDIT, SPINEDIT widget you would get the applicable native widget.  The upside is that the user gets a consistent user experience with other applications on their mobile device.  The downside is that there isn’t always a 1-1 correspondence between a 4gl Attributes, 4gl Presentation Style and what the native widget is capable of.   This is most noticeable with the date format where the widget will use the native format setting rather than the 4gl FORMAT setting.
 
How this is implemented is a good lesson in GBC Customization , the concept of Widget Instantiation Overrides, and the use of Theme Conditions. 

Read more at https://4js.com/ask-reuben/ig-264/

When resolving an issue, and we have determined that we need to provide some form of fix to our product, a question that we will ask is along the lines of “when would you like this fixed by?”  We are both in the software development business and regular issues are not resolved by stopping whatever we are working on, fixing an issue and then delivering it straight away.  There is normally some form of release cycle /  release procedure involving QA, and the new work needs to be scheduled in amongst the existing planned workload.
 
I tend to find customers are “too nice” when answering the question of “when would you like this fixed by”.  For example, if you are making some enhancement to meet new government requirements that come into effect on 1st July, your answer should not be “1st July”.  You may have some QA, parallel runs, code freezes that need to take place beforehand, so your answer should probably be “1st May” along with an explanation why.

Read more at https://4js.com/ask-reuben/ig-263/

Hi Jeff,

I'd expect it to work.  It is documented as doing so. https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_menus_004.html

There has been odd issue many years where it would popup in the wrong place https://4js.com/support/issue/?product=GBC&stat=&fixed_in=&words=popup+menu&Search=Search so I'd wonder if it was appearing off screen or is similar to some of those prior cases.

Suggest you try the example in the documentation, and raise a support call where you can provide more details.

Reuben