Is there a workaround to update a screen variable when you o

Posted by MGreenwood on 31-Jan-2019 14:44

Hi All, 

Running OE10.2B

We have a feature in our software that allows a user to modify widgets on a screen. 

We build a replica of the screen, allow users to specify changes (i.e. change labels, change the location of a widget apply validation to a widget) and store the changes with the Widget Handles via XML. 

A customer has said "It would be great if you could convert text entered to FORCE CAPS, which happens elsewhere in the system for Postcodes."  

The problem of course is that as per KBase articles 

https://knowledgebase.progress.com/articles/Article/000043405 
HOW TO ASSIGN THE INTERNAL VALUE OF A FILL-IN WIDGET VIA ITS HANDLE

https://knowledgebase.progress.com/articles/Article/P108106

GIVEN A WIDGETS HANDLE CAN YOU ASSIGN ITS SCREEN-VALUE TO THE UNDERLYING VARIABLE/DATABASE FIELD?  

"... it is not possible to directly assign the handles SCREEN-VALUE attribute to the underlying variable (or database field) because the widget handle does not know about the underlying variable (or database field). The widget handle knows only about the graphical (UI) widget. ..." 

The code that executes the validation is contained in an include which is present in 1700+ screens and in most if not all screens it's after the assignment of the screen values which, of course moves the screen-value into the underlying variable. 

As we do not want to have to check and move this include in all of those screens can anyone suggest a solution to the question "GIVEN A WIDGETS HANDLE CAN YOU ASSIGN ITS SCREEN-VALUE TO THE UNDERLYING VARIABLE/DATABASE FIELD?" 

All Replies

Posted by Patrick Tingen on 31-Jan-2019 15:20

Since there /has/ to be a connection between the widget and the variable in order to assign the latter, the only option I see is to move at least some of the validation logic into the assign - part. If you are able to turn the widget's content to caps then the assign code will take care of it.

( Now, I could start a rant on why includes are used to pave the way to hell, but you already found out .... )

Posted by MGreenwood on 31-Jan-2019 15:42

Thanks for the response Patrick we are trying to generate a "generic" solution in our legacy system.  

Your suggestion would require us to at least check if not change @1700+  screens. This is not a route we( I !) wanted to go down.

Posted by Stefan Drissen on 31-Jan-2019 20:34

Not sure if I'm understanding your question correctly, but you can apply caps from a trigger:

def var ficc as char no-undo view-as fill-in.

def frame fr
   ficc 
   . 
   
enable all with frame fr.
view frame fr.

run triggers (frame fr:handle).

wait-for close of frame fr.


finally:
   message frame fr ficc view-as alert-box.
end finally.


procedure triggers:
   define input parameter i_hfr as handle no-undo.
   
   def var hw as handle no-undo.
   
   hw = i_hfr:first-child.

   do while valid-handle( hw ):
      
      if hw:type = "field-group" then 
           run triggers ( hw ).
   
      else if hw:type = "fill-in" then       
         on any-printable of hw persistent run capsit ( hw ).
      
      hw = hw:next-sibling.
   
   end.     
   
end procedure.   

procedure capsit:
   define input parameter i_hw as handle no-undo.
   
   apply caps( last-event:label ). 
   
   return no-apply.
   
end procedure.   

Posted by MGreenwood on 01-Feb-2019 14:51

Hi Stefan,

Thanks for your input on this I'm not you have understood what we want to do although I'm not sure I have explained it well enough.

However I did try to implement your "APPLY CAPS" suggestion but this did not have the desired effect .

From a window > {call DYNAMIC-FUNCTION in separate p code}

    Read from DB list of widgets to have validation / formatting applied

           using the widget handle validate the contents  i.e. assign the current screen-value to a local variable and validate the contents

           <*New Feature Requested *  in some manner, with only the widget handle available to us, update the contents of the widget >

I hope the additional explanation helps

This thread is closed