Answered Dynamically adding labels and fields to appbuilder screen

[whwar9739]

Good afternoon all!

I am currently working with an older .w appbuilder screen and have been tasked with adding labels and fields to this screen based on values in a table. Essentially the table contains a label and a format. There is more information but it isn't pertinent to the question. So I will need to be able to do the following:
1) if there are no entries in the table leave the screen as is
2) if there are entries, add a rectangle (box) and have that dynamically expand to fit labels and entry fields, plus move down the ok and cancel buttons that currently exist on the screen.

I'm having a hard time visualizing what the code will eventually look like. Any small examples you might have would be greatly appreciated.

 

[TheMadDBA]

Look into the various CREATE (widget) commands and the widget attributes...

Here is an example from the KB to create a dynamic button as a starting point (fill ins are very similar from a coding perspective): http://knowledgebase.progress.com/articles/Article/P13481

Here is an example on how to resize/move existing widgets based on a window resize: http://knowledgebase.progress.com/articles/Article/000056589

You probably don't need your button moves to be as complicated as the code in the second KB, but it gives you the widget attributes you care about.

 

[whwar9739]

Ok so this got me much closer to my goal, but it isn't functioning like I would like. Of course the first field I am trying to create is an amount field with thousands separators and decimal point.
If I try to set the format to be "zzz,zzz,zz9.99" then the field on the screen ends up looking like this: |zzz,zzz,zz . |
If instead I set the format to "999,999,999.99" it then looks like this: | , , . |
Using "|" to show ends of the field.
I've tried setting the screen-value that doesn't seem to change the outcome. I'd like the field too act just like the view-as for a decimal field that is formatted as "zzz,zzz,zz9.99".

Would it be better, or maybe even possible to do something with a dynamic temp-table?

 

[Cringer]

A dynamic temp table won't help you.
Maybe if you show us the code (paired down and in [code][/code] tags) we can help spot the problems?

 

[TheMadDBA]

Make sure you are setting the height and width properly when you create the fill-in. Also post your code like Cringer suggested and your exact OE/Progress version.

 

[whwar9739]

That I can do Cringer!
Also using 11.5

The udn table has the following schema:
notice as int
sequence as int
descr as char
type as int
req as log
val-desc as char

   FOR EACH udn NO-LOCK
      WHERE udn.notice = 1
      BREAK BY udn.notice
            BY udn.sequence:
      IF FIRST-OF(udn.notice)
      THEN DO:
         ENABLE RECT-55 WITH FRAME Dialog-Frame.
         RECT-55:HIDDEN = FALSE.
      END.
    
      /* Label */
      CREATE TEXT h-udlabeltmp
       ASSIGN
         FRAME        = FRAME Dialog-Frame:HANDLE
         ROW          = RECT-55:ROW + RECT-55:HEIGHT
         HEIGHT       = 1
         COLUMN       = 4
         SCREEN-VALUE = udn.descr
       .
    
      CASE udn.type:
         WHEN 1
         THEN DO:
            CREATE FILL-IN h-udfieldtmp
             ASSIGN
               FRAME        = FRAME Dialog-Frame:HANDLE
               ROW          = RECT-55:ROW + RECT-55:HEIGHT
               HEIGHT       = 1
               COLUMN       = 30
               SENSITIVE    = TRUE
               VISIBLE      = TRUE
               WIDTH        = 25
               LABEL        = udn.descr
               DATA-TYPE    = "DECIMAL"
               READ-ONLY    = FALSE
               FORMAT       = "zzz,zzzz,zz9.99":U
/*               SCREEN-VALUE = "          0.00"*/
            .
         END.
         WHEN 2
         THEN DO:
         END.
         WHEN 3
         THEN DO:
         END.
         WHEN 4
         THEN DO:
         END.
         WHEN 5
         THEN DO:
         END.
      END CASE.
    
      RECT-55:HEIGHT = RECT-55:HEIGHT + 1.34.
    
   END. /* for each prmtudn */
 
 
   IF RECT-55:VISIBLE
   THEN DO:
      cmdSave:ROW = RECT-55:ROW + RECT-55:HEIGHT + .14.
      cmdCancel:ROW = cmdSave:ROW.
      FRAME Dialog-Frame:HEIGHT = cmdSave:ROW + cmdSave:HEIGHT + 0.86.
   END.

 

[whwar9739]

And to your comment, TheMadDBA, height and width on the widget itself looks just fine.

 

[TheMadDBA]

Move the data-type and format to the top of the assign statement. I am getting an error with your code saying that the fill-in is already realized and the data-type can't be changed.

 

[whwar9739]

Well don't I feel stupid now! Thank you so much!! That fixed it and now it looks exactly as I expected.

 

[whwar9739]

One last question for you then. Where were you seeing an error? Just for future knowledge if I run into something like this again.

 

[TheMadDBA]

When I ran the create fill-in code that you supplied above I got a windows error pop-up with the message. You should have received the same error if you were running that code.

 

[whwar9739]

Strangely, I was getting no errors at all. Now I was only running that code within the whole of my program, never as stand alone. There quite possibly is code elsewhere in the program that is suppressing the errors. Again thanks everyone for your help.

 

[whwar9739]

Okay, so now I have another question related to this same topic.
How would one best store the handles for the new dynamic widgets? I need to be able to access them later in other code besides just flipping through all of the widgets.


****nevermind I think I just figured it out****
I can save the handles as strings in a delimited list, and then use HANDLE(ENTRY(x,list,",")) to get the handle back.

 

[Cringer]

Nooo don't do that! lol That's terrible!
Store them in a temp-table.

 

[whwar9739]

Ohy, why didn't I think of that?!?! This project has run me over, reversed, run me over again, in drive and ready to run me over again.

 

[Cringer]

lol you'll love it by the end!
The other advantage of a temp-table of the records is that on close of the screen you can trawl through and delete the objects. In theory as the screen goes out of scope all the objects should clear down, but no harm in making sure.

 

[whwar9739]

Not to mention, I can toss more information, such as value, into it and pass the whole thing around, since these values will eventually need to be passed to a print routine that needs other information.

 

[Cringer]

Just pass the handle round. You can get all the properties (such as values) from the handle so why waste memory passing stuff around redundantly?

 

[whwar9739]

There is just other information I needed that I needed as well. Mostly stuff from the original table that I used to build the fields from in the first place.

 

[Cringer]

Fair enough than In a lot of ways going dynamic is a lot of fun. Just try and keep the code as clear and as simple as possible so you can fix it later