next »

[Andrew C.]

After changing our development from 2.11 to 2.20.09, I'm cleaning up the broken programs. In several I see code like the following remarkable example:

Code

      if p_dmrefn.fil_typ is not null
      and p_dmrefn.fil_typ matches [0-9]
      then
        select doc_dsc into p_dmrefn.doc_dsc from audmmprm
 

Anyone who can't see it, look again closely. Now the 2.20 compiler is correctly complaining. I never even conceived to try that crime before. Was it ever legal for Informix RDS? I hope not...

Another thing I've found is an improvement to the detection of illegal fields. Consider this paraphrased slab of code:

Code

define
    k_rec record
        key_num integer
    end
 
function blah()
    ....
 
    delete from some_tab
      where some_tab.trn_num = k_rec.trn_num
 

In the past, Informix and 4JS would fail to find k_rec.trn_num as a legal variable so it would assume it's a table in the database and allow the database engine to worry about it. Now, the 2.20 compiler is thinking:

k_rec is a real record, so we know it's a variable reference. However, trn_num is not a field of k_rec so issue an error.

This is A Good Thing. I like it, although it might cause problems for people with particularly bad ambiguity in their table and variable naming conventions. What I don't like is the dozen or so samples in allegedly correct working code of ours that have now been caught by this compiler improvement!

Please keep these improvements coming; but can we get these sorts of things documented in a new-features page? I don't recall seeing either of these changes mentioned in the New Features section of the 2.20 BDL manual. Am I failing to find a more technical file describing stuff like this?

[Reuben B.]

Andrew, 

Are you aware of the migration issues pages?

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/Mig0004.html
https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/Mig0004.html#strict_sql_params

Reuben

[Andrew C.]

Not really, although I have a few neurones sparking half-heartedly, so maybe I used to know...

This is exactly what I'm thinking about, however the page doesn't mention the MATCHES issue, and it doesn't mention another phenomenon I've noticed; our existing library code enables/disables MENU commands by finding the om.DomNode of the "MenuAction", and then setting the "active" attribute to 0 or 1. Now that the new ui.dialog.setActionActive() call has been introduced, the setAttribute() call on the node is being quietly ignored.

I don't mind this kind of change (and it's not the first one over the last few years) but knowing about it would be nice. I'd even be happy with a runtime exception that blew up when I tried to set the "active" attribute rather than quietly ignoring it.

I've also just found out that setting the "active" attribute on "Action" nodes (super-partner of the MenuAction node) is also being ignored. I should have guessed, but at least it's in a library function...

I know personally how hard it is to note down and share every tiny little change I make to our tools, so I fully sympathize. However I'm being nagged by my superiors to improve my notes so it's only fair I pass it on ;-)

Cheers

[Reuben B.]

Think of the migration issues page as being what you HAVE to read, and the new features pages as being what is INTERESTING to read :-).  I don't know what link you used for New Features but they are in the same section here https://4js.com/techdocs/genero/fgl/devel/DocRoot/index.html (top right corner)

Other places where the information may appear is ...

$FGLDIR/etc/readme.txt
$FGLDIR/etc/changes.txt

I suspect the MATCHES issue is a square braces issue and is related to bug 7715 which was corrected between 2.20.04 and 2.20.05.  This is mentioned in both the .txt files although with the barest of expressions "Internal error when using square brace expression".  Prior to then, this code quite happily compiled ...

Code

  DISPLAY LENGTH(["P", "E"])
 
  CASE ["P","E"]
    WHEN "a"
  END CASE
 
  RUN [1,2,3]

but failed at run-time.  Looks like your example quite happily ran at run-time.

With regards to the DomNode changes, over the years the message has been fairly consistent with regards to manipulating the DOM...

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

... if you do have code that manipulates the DOM then please ensure that you participate in Early Access Programs so as to at least ensure that your code still functions, or you can modify your code efficiently so that it still functions, or we can make the necessary changes to ease any pain.  Methods such as ui.Dialog.getCurrent() https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/ClassDialog.html#getCurrent were implemented as result of comments in Early Access Programs.  The 2.20 EAP was over 9 months ago, and the 2.21 EAP closed with the release of 2.21 last month.

Reuben

PS Why 2.20.09? 2.21.01 is the latest release.

[Sebastien F.]

I second Reuben. Why not using 2.21? This version is now released!
Seb

[Andrew C.]

I tagged along on the 2.20 EAP but did not find the "active" issue personally. I doubt it's possible to discover everything; the failure of setting "active" was first noticed by a programmer some weeks after we cut them in.

over the years the message has been fairly consistent with regards to manipulating the DOM

Yes, we got that message from the very first training way back; no argument there. However things DO have to work a certain way so the DOM code had to be written until it became part of Genero these years later. What's a little bit puzzling is the way the setAttribute power is cut off without any period of grace, and maybe some sort of errorlog trace. I'd be happier if the change brought a runtime fault rather than just quietly ignoring the call.

Fortunately the code IS in a library routine so it's trivial to fix the system. Now that I think about it, I might have a grep around to see if anybody has hand-coded anything low-level in application code; that might be scary-interesting...

As for why 2.20 vs. 2.21, that's simply because the decision was made before 2.21 was locked down. I also doubt we'd ever manage to get the very latest into a new release unless there was exceptional synchronisity in the dates of the releases. Also some people are very nervous about the latest release of any software, no matter how enthusiastic I may be about using it.

Just for interest's sake, is there a bug-fix or release note describing the increased analysis of inline SQL - the fix that has resulted in the compile error of the k_rec example?