In v10.1 it is proposed (provisionally) to drop support for choose/scroll statements and to remove them in v10.2. We would have to change 1500+ character programs running on Unixware that make use of these 2 statements.
I cannot imagine that we are alone in this? Anyone else?
What significant advantages do Progress gain in dropping these statements? At best a slightly smaller executable and a little bit less testing for new releases?
Progress claim that the choose statement can be replaced by a selection list or a browser but this is simply not the case. The most obvious difference is a browser shows only a single row of information where as a choose statement on a down frame can be for multiple lines not just a single row. Browsers (especially updateable ones) are also more awkward to code compared with the simplicity of choose.
Finally it would seem a backward step to remove existing widely used, simple and powerful functionality from a Character Environment.
Carl Williams
Technical Analyst.
Business Computer Projects Ltd
Carl,
We are not planning to remove the deprecated features and functionality from the product. There's a document that includes information about this, but there is a typo and we are in the process of correcting it.
We are planning to wrap the deprecated features with a compiler (and/or a startup) parameter to provide a warning to the users when using these features. However, again, there is no plan to remove the functionality from the product.
The objective of the deprecation is to set the expectation that those features are considered obsolete and therefore customers should start planning accordingly, having plenty of time (multiple releases, 10.0, 10.1, 10.2, etc.) to proceed.
Finally, the deprecation is exclusive to OpenEdge 10, no change is being done to V9, that would compromise existing deployments.
Please let me know if you have questions or concerns.
Regards,
Salvador
We are not planning to remove the deprecated features
and functionality from the product. There's a
document that includes information about this, but
there is a typo and we are in the process of
correcting it.
We are planning to wrap the deprecated features with
a compiler (and/or a startup) parameter to provide a
warning to the users when using these features.
However, again, there is no plan to remove the
functionality from the product.
The objective of the deprecation is to set the
expectation that those features are considered
obsolete and therefore customers should start
planning accordingly, having plenty of time (multiple
releases, 10.0, 10.1, 10.2, etc.) to proceed.
Finally, the deprecation is exclusive to OpenEdge 10,
no change is being done to V9, that would compromise
existing deployments.
Please let me know if you have questions or
concerns.
Regards,
Salvador
Well, that's all fine and good, but, to reiterate the original point: this is a BACKWARDS step for CHUI interfaces. That's not really a surprise I suppose, since everything Progress has added since V8 has been broken in some stupid way in CHUI (no dynamic browses, half the dynamic properties don't exist in CHUI, etc)
Those of us who develop and use CHUI and are quite satisfied with it, thank you, would be extremely hampered by the removal of features that are, granted, very CHUI oriented. How about, instead of dropping these features across the board, just drop them from GUI interfaces. It's not like you're not already treating us CHUI people the same way with a lot of the new dynamic interface features...
I was thinking about this again last night while trying to get to sleep, and it dawned on me that there is one other case where removing something like CHOOSE would be bad: multi-column selects. We have a CHUI pricing screen, that needs to show a maximum number of records in one page. In our case, using a CHOOSE, we crammed 48 records into one screen. Switching to a browse would result in a max of 15 records (16 if we eliminated the frame). This would KILL our pricing analysts, since the larger view allows them to get a better picture of pricing in one glance.