Four Js Customer Forum

    DEFINE w ui.Window,
           f ui.Form,
           nw, nf, o om.DomNode
           
    LET w = ui.Window.getCurrent()
    LET nw = w.getNode()
    CALL nw.setAttribute("text", "Form1")
   
    LET f = w.createForm("F1")
    LET nf = f.getNode()

    LET o = f.createChild("label") --> Here I get this error :

                                                           FORMS statement error number -8003.
                                                           Dom: A node is inserted somewhere it doesn't belong.

How to resolve this ?
Thanks in advance.

Miguel,

You cannot directly create a Label node under a Form node, for ex, see a .42f file produced from a .per with fglform.

For a complete definition of the AUI tree, see FGLDIR/doc/dtd/UserInterface.dtd

Note however that we may change that definition in future version, try to centralize as much as possible the creation of dynamic form elements.

Note also that you mist use "Label" with a capital letter.

Seb

I would also recommend to be very careful when building dynamically your form.

Some attributes are mandatory and the checking is done directly by fglform - your aui tree may be correct from a DTD perspective, but not from the application point of view ; so you may encounter very strange results as the front ends expect some attributes to be defined the way fglform does.

GDC also expects to have some attributes at creation time, so if you make something like


myLabel.setAttribute("posX","2")
CALL ui.interface.refresh()
myLabel.setAttribute("posY","5")


posY = 5 will be ignored, as the widget will be created once ui.interface.refresh() is called, at this time posY equals 0, and GDC does not manage further changes of posY attribute.

So please make sure your form is created the same way fglform would create it.

I second Pierre-Nicolas.

Note that fglform can execute with a runtime license, so normally you could generate a .per form dynamically, compile it from the program with
RUN "fglform ..."
and then load it with om.DomNode.loadXml() ...

I did not test but you could give it a try... I would use files in /tmp of course with process id to avoid conflicts with other users.

Seb

Thank you very much, to all.

DEFINE w ui.Window,
           f ui.Form,
           nw, nf, ng, o om.DomNode
           
    LET w = ui.Window.getCurrent()
    LET nw = w.getNode()
    CALL nw.setAttribute("text", "Form1")
   
    LET f = w.createForm("F1")
    LET nf = f.getNode()

    LET ng = f.createChild("Grid")

    LET o = ng.createChild("Label")

This works :)
-------------------------------------------------
But if I try


LET ng = f.createChild("Tree") or
LET ng = f.createChild("Table")  or
LET o = ng.createChild("Edit")    --> Here I get this error :

                                                           FORMS statement error number -8003.
                                                           Dom: A node is inserted somewhere it doesn't belong.

How to resolve this ?
Thanks in advance.

Miguel, you should run the table demos and look in the GDC in debug mode (gdc -aD) via Control-Right click in the AUI tree inspector how the real table structure looks like. You can also create a simple form containing a table and look in the resulting .42f file how the structure looks like.
Any attempt to create an invalid structure is fortunately blocked by the run time system, however even if the structure is ok, there may be semantic errors as Pierre Nicolas and Seb pointed out. You should already program a while in Genero before you start to make AUI tree manipulations. If you are an expert however, creating forms on the fly can be an option to save the creation of a lot of boilerplate forms.
Kind Regards, Leo

Miguel,

May I ask why you need to generate forms dynamically?
Remember the AUI tree is subject of changes between major product versions.
Note also that fglform has special rules when generating the .42f from the .per.

Leo:
Don't you think it's more safe to generate a .per file on the fly, then compile with RUN "fglform ..." and then load the 42f with OPEN FORM / DISPLAY FORM or OPEN WINDOW .. WITH FORM? Am I missing something? Why would this not work?

Seb

Seb,yes: creating complete new forms on the fly should go thru fglform. I should have made that more clear.

Thank you, to all.

Quote from: Sebastien FLAESCH on July 26, 2010, 03:42:20 PM
...
Note that fglform can execute with a runtime license...

can we get that added to the documentation somewhere.  I wasn't aware of it.

Quote from: Leo Schubert on July 30, 2010, 05:53:15 PM
...
creating forms on the fly can be an option to save the creation of a lot of boilerplate forms.
...

... in order to utilise creating forms on the fly, we ought to be able to create dialogs on the fly as well.  I have a generic zoom window routine that could potentially create forms on the fly but without generic dialogs I have a DISPLAY ARRAY of an arbitrarily large number of columns, and then hide the columns I don't want to see.   I'd love to have a generic table maintenance routine but at the moment the only way to do that is with an INPUT/INPUT ARAY/CONSTRUCT using an arbitrary large number of fields.

Quote from: Reuben Barclay on August 03, 2010, 12:50:02 AM

Quote from: Sebastien FLAESCH on July 26, 2010, 03:42:20 PM
...
Note that fglform can execute with a runtime license...

can we get that added to the documentation somewhere.  I wasn't aware of it.

Warning added to doc:

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/Tools.html#TL_FGLFORM

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/Installation.html#INST_LICENSING

Good morning,

I've got a menu with some action, then I create another MenuAction at run time. The button is shown on the menu, but when I click on it, nothing happens why ? How can I catch the event or fire the event of that menu button ?

LET nMa = nMenu.createChild("MenuAction")
CALL nMa.setAttribut("name", "dosomething")

Runtime team will confirm, but you're taking the concept in the wrong way here. Let me explain:

the AUI tree is the result of a combination between:
1. the forms read from .per files (mostly: the FORM node)
2. business logic from your 4gl code (moslty: DIALOG / MENU nodes)

So the sum of these two items produces the AUI tree which is sent to the front ends which render GUI.

If you create manually MenuActions, you just add an entry in the AUI Tree ; but there is no business logic behind, the 4GL runtime has no idea on what it has to do when the button is clicked.

To get an imaged view, let say you gave the construction plan (.4gl) to your electrician. He will then add some switches on the wall and add wires from the switch to the main switchboard.
By adding manually menuactions, you're just addin switches on the wall ; but you're not adding the wires - and you can't, only the electrician can.

This is one of the lacks of 4GL today: you can't build a generic interface from scratch, there are still some pieces that need to be hardcoded in your 4GL file.

As a workaround you can do something like

MENU
  COMMAND "a"
  COMMAND "b"
  COMMAND "c"
  COMMAND "d"
   ...
  BEFORE MENU
    IF do_some_tests() THEN
      CALL set_actions_xxx_enabled(TRUE)
   ELSE
      CALL set_actions_xxx_enabled(FALSE)
  END IF
...


where the function enables or disables the corresponding actions...

with a sufficient number of COMMANDs.

Tank you Mr Pierre Nicolas Rigal