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?"
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 .... )
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.
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.
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