ProTop I can see ... but end user UI it is very non-intuitive to display stuff that people can't see and especially if one then acts as if one knew they had seen it.
Of course, one could see this as a signal that it was time to get off of 1251, a character set that is really not up to modern demands, and move to UTF-8 overall and not have to do stuff like this.
Let me add another vote for the PUGgy events. In particular, both at these events and through any other channels you can find, the key goal is to find a champion at Progress. Finding one will make a night and day difference in the attention you can get. A good route might be to develop a talk...
I'll bet that the vast majority of cases are easily encapsulated, some take a bit of thought (which becomes routine after the first few), and a small number are genuinely difficult ... but that often the difficulty exists in the non-OO implementation as well.
Why not encapsulate the for each in the same object as the temp-table? One of the benefits is that one can change the definition of the temp-table and its access without changing the methods of the object.
Echoing the horror of others, one really needs to be clear about what one needs and wants at run time versus what one needs and wants at compile time. If all you are doing is displaying a value, then you need nothing more complicated than a run time parameter to pass in the value. Oh, and...
One might also note that with good paid help, a huge amount of your time is likely to be saved ... not to mention the predictability and quality of the result ... not to mention the opportunity for learning.
My inclination would be:
if last-of (tf-tray) then do:
find first hist no-lock where hi-itm = if-item-no no-error.
if not available (hist) then disp tf-tray.
end.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.