Prompt-for - deprecated in V10?
- Thread starter Skc
- Start date
if you look at modern interfaces with tab folders, toolbars, panes etc.
though its hard at the moment with progress. but its been said that its their
number one priority for the next full release
theres lots of work been done with ajax and .net. there will, probably, some
out of the box controls etc.
its hard to impossible to define their behavior with a process. for example,
that does 1, 2, 4 or a loop etc.
they're event-driven and i'm guessing thats where they're putting
their effort.
your programs will still compile you'll just get a message to remind you.
here's a code sample
you can read more about event-driven and procedure-drive procedure flow
in the programming handbook doc. hth
moving out now. i'll be back soon
though its hard at the moment with progress. but its been said that its their
number one priority for the next full release
theres lots of work been done with ajax and .net. there will, probably, some
out of the box controls etc.
its hard to impossible to define their behavior with a process. for example,
that does 1, 2, 4 or a loop etc.
they're event-driven and i'm guessing thats where they're putting
their effort.
your programs will still compile you'll just get a message to remind you.
here's a code sample
Code:
form
item.itemnum
with frame a.
repeat /* with frame a */ :
enable all with frame a.
wait-for "go" of frame a.
disable all with frame a.
message
input frame a item.itemnum /* item.itemnum:screen-value in frame a */
view-as alert-box.
end. /* repeat */you can read more about event-driven and procedure-drive procedure flow
in the programming handbook doc. hth
moving out now. i'll be back soon
Yes you are right that the only possible option is to replace the prompt-for with 3 commands: enable, wait-for and disable. But isn't it easier to use only a single prompt-for? It's sometimes not a straight-forward 3 for 1 replacement. There's a need to also take care to disable the widgets when user presses the end-error key and to handle it properly if its within triggers and so on....
I am now using OE10 but I remember in V7 Progress, having multiple wait-fors within an application or a procedure cause it to bomb. Since then I have confined wait-fors only in the first 1 or 2 procedures.
But the question is why deprecate prompt-for? Does it interfere with Progress advancement? Prompt-for is actually part of the SET and UPDATE command. So in theory Set and Update should be deprecated too.... but of course I hope they don't do that !
I am now using OE10 but I remember in V7 Progress, having multiple wait-fors within an application or a procedure cause it to bomb. Since then I have confined wait-fors only in the first 1 or 2 procedures.
But the question is why deprecate prompt-for? Does it interfere with Progress advancement? Prompt-for is actually part of the SET and UPDATE command. So in theory Set and Update should be deprecated too.... but of course I hope they don't do that !
I've just been reading PSC's Platform & Product Availability Guide. I see that the EDITING statement is deprecated as of 10.1A with a replacement feature of a WAIT-FOR, then PROMPT-FOR is being deprecated as of 10.1B with a replacement feature of SET or UPDATE.
I thought I'd post this as a warning, I'd hate to think of anyone having to re-engineer their app. twice in such short succession!
Back to the topic of this thread though, at least this means you could replace the PROMPT-FOR with ASSIGN & SET statements without having to rip up too much of your code - as long as you don't use EDITING...
I thought I'd post this as a warning, I'd hate to think of anyone having to re-engineer their app. twice in such short succession!
Back to the topic of this thread though, at least this means you could replace the PROMPT-FOR with ASSIGN & SET statements without having to rip up too much of your code - as long as you don't use EDITING...
It's the other way round. SET can be replaced by PROMPT-FOR and ASSIGN. The Progress recommendation of replacing PROMPT-FOR with SET or UPDATE is NOT right.
TomBascom
Curmudgeon
"Deprecated" just means "we strongly advise you to find a better way". They might someday have the compiler start issuing warnings about these things but they aren't going to remove it from the language.
If you're writing new code that uses PROMPT-FOR then you are doing something that is very, very wrong.
It hasn't been a good idea since 1992.
If you're writing new code that uses PROMPT-FOR then you are doing something that is very, very wrong.
It hasn't been a good idea since 1992.
Would you be kind enough to explain why it is not a good idea? Or could you point to some documentation? I would be interested to know why and whether any recommended alternative is indeed better.
TomBascom
Curmudgeon
Prompt-for is very much the embodiment of a procedural user interface.
As a skill event driven thinking is more important than any particular tool, more important than GUI, more important than object orientation and it is much more important than cataloging the gory syntactical details of version X vs version Y or this that and the other widget, method or attribute.
Event driven user interfaces are more flexible and modern. And they are where all of Progress' user interface focus is (and every other tools vendor for that matter.) So whether your interest is to provide the best interface for your users or to sharpen your personal skills for the marketplace you should learn about event driven coding. In the world of Progress that means that you need to understand ENABLE, WAIT-FOR and UI Triggers. You should also get friendly with Persistent Procedures (although they aren't strictly necessary and if you're in the midst of a legacy character environment they might not be as helpful as they otherwise would be).
If you do not learn these things then you can expect to become increasingly marginalized as a programmer. And that's not something to look forward to.
As a skill event driven thinking is more important than any particular tool, more important than GUI, more important than object orientation and it is much more important than cataloging the gory syntactical details of version X vs version Y or this that and the other widget, method or attribute.
Event driven user interfaces are more flexible and modern. And they are where all of Progress' user interface focus is (and every other tools vendor for that matter.) So whether your interest is to provide the best interface for your users or to sharpen your personal skills for the marketplace you should learn about event driven coding. In the world of Progress that means that you need to understand ENABLE, WAIT-FOR and UI Triggers. You should also get friendly with Persistent Procedures (although they aren't strictly necessary and if you're in the midst of a legacy character environment they might not be as helpful as they otherwise would be).
If you do not learn these things then you can expect to become increasingly marginalized as a programmer. And that's not something to look forward to.
Prompt-for is the high-level equivalent or combination of 3 commands: enable, wait-for, disable. Using prompt-for and even higher-level commands like SET or UPDATE has not stop me from coding and using UI triggers in relation with them.
The only difference I can see is that in wait-for, you probably can code for more events.
TomBascom
Curmudgeon
The "high level" conceptual combination of enable, wait-for, disable is at a microscopic level and only spans the moment. The only enabled widget is the target of the PROMPT-FOR. At best you're creating the equivalent of a modal dialog box with PROMPT-FOR.
PROMPT-FOR is more often the embodiment of procedural code. It sits in-line in code that flows in a fixed manner. Even though there may be conditional logic the code controls what happens next, not the user. The code moves from UI element to UI element in a programmed manner. You go from field to field in a certain order (which may be complex and may be flexible if you've programmed it to be so) and there are certain actions that take place if the code passes through certain paths. The coupling between interface and action is very tight.
In an event-driven interface you prepare the interface, present it to the user and then the code waits for events from the user and acts on them individually. The coupling between interface and action is very loose.
The difference may be subtle, and perhaps I'm explaining it poorly but it is very important.
PROMPT-FOR is more often the embodiment of procedural code. It sits in-line in code that flows in a fixed manner. Even though there may be conditional logic the code controls what happens next, not the user. The code moves from UI element to UI element in a programmed manner. You go from field to field in a certain order (which may be complex and may be flexible if you've programmed it to be so) and there are certain actions that take place if the code passes through certain paths. The coupling between interface and action is very tight.
In an event-driven interface you prepare the interface, present it to the user and then the code waits for events from the user and acts on them individually. The coupling between interface and action is very loose.
The difference may be subtle, and perhaps I'm explaining it poorly but it is very important.