Abe Froman
Member
I have a specific question tied to a more general question.
A button runs a report. The HELP attribute on that button tells users what will happen when you hit the button (if they tabbed to it).
I want my ON CHOOSE OF trigger to do some validation, change the status bar message to "Running report...", and run it. The trouble is overriding the HELP attribute of the button.
In searching for answers here, there is a lot of talk about the STATUS statement. After trying many variations, I came upon this key piece of info in the reference.
Back to the problem. In a trigger. Need to change the status display while a report is running. HELP attribute is being a bully. Changing the HELP attribute doesn't get displayed. STATUS DEFAULT only displays when a message from the running report gets displayed at the end. That is too late.
I am tired of playing all morning with what should be a simple task. Can it be done? Or do I have to hatchet the existing code, remove the HELP attributes and add a bunch of STATUS statements? Am I better off tearing up the code worse and making a pseudo status area at the bottom of the frame and having total control of my own status message var? How could this be so difficult and how could this not have been addressed yet in some thread here (he cried to the heavens...)
-----
Concerning the general question, am I asking too much from this forum? Is it too much to ask that Senior ProgressTalkers add to their long and definitive answers some warning that omitting a key fact or a slight change in environment will cause the situation to completely change and cause you to grind your gears for an afternoon trying to get their solution to work?
Progress is powerful. There are a multitude of options to give you more control. Every situation cannot be guessed by those trying to help. Yadda yadda yadda.
There have been too many times that I've been let down by the omission of warnings of some of the pitfalls. Other times, the answers have been so situational as to be useless as any kind of general solution.
For example, I am working on a dynamic query and updatable browse mega-utility. I understand enough to realize there can be no template for such a browse that would meet all needs (although when I'm done with mine, I'll have a nice template for viewing and updating parameter tables, but I digress). The point is it still shouldn't be brain surgery. I can't tell you how many times I've gone down a road based on advice from a thread here and had to backtrack and start a new path.
I can only get to screen values of the browse updates to validate before saving them by referencing the Screen-Value of the ColumnHandle ??? OK, Progress... But that means I need to define the browse in such a way as to store the column handles. Which means that formatting the columns needs to be handled outside of the browse definition. BUT, if you do it in the browse-row-display trigger, you'll have errors if you need to set the browse to Read-Only while validating, so the only way to do it is to manually format the fields in your temp table. So, you can't use LIKE to define your temp table and must manually define all the fields. Progress may be powerful, but they could use a few more methods to make having complete control over a browse stop being a convoluted nightmare.
AT LAST TO THE EXAMPLE. In trying to loop through the browse rows (so I could get at the screen values through the column handles), I needed to select the first row and then iterate through them, working on the modified ones. MORE THAN ONCE, ProgressTalkers suggest using the SELECT-ROW method in similar situations. Nowhere in all the examples I was looking at was it mentioned that this method only starts on the rows IN THE VIEWPORT. Thank god I caught it in testing, but it worked when I had the first row in the browse in sight, but skipped all records above when I was scrolled down a page or more.
Of course, it's in the reference help for the method (once at the beginning), but the help also states:
I didn't know whether to be more angry at ProgressTalk or Progress itself. Should their reference be clearer? Yes. Should they have a method (or at least an option in the current method) to select the first(!) row of a browse? Yes. If they want me to use the QueryHandle instead, they should have given me a way to access its Screen-Value.
Should ProgressTalk have already gone through this gauntlet? Yes. I mean, if ProgressTalk doesn't even have browses mastered, I'd be better served by praying for advice instead of looking it up.
I wonder if the knuckleheads using some variation of Select-Row(i) to iterate through their browses have realized their danger and simply not annotated their advice here, or do they luckily only use browses that don't scroll? Or maybe they have bugs in their code and swaths of browse rows are being ignored.
I am often wrong and am not too prideful to admit it. If this is all my misunderstanding, then I will apologize whole-heartedly. If not, where can I go for advice when my shop hasn't any relevant examples and it's too complicated for ProgressTalk to give a complete answer? Or am I doomed to reinvent the wheel all by myself every so often in dealing with the six-faced and three-hearted Progress when all I need is a good example to learn from?
A button runs a report. The HELP attribute on that button tells users what will happen when you hit the button (if they tabbed to it).
I want my ON CHOOSE OF trigger to do some validation, change the status bar message to "Running report...", and run it. The trouble is overriding the HELP attribute of the button.
In searching for answers here, there is a lot of talk about the STATUS statement. After trying many variations, I came upon this key piece of info in the reference.
OK, so that's why I am spending so much time trying "solutions" that will never work. Once again, ProgressTalk lets me down. We'll get back to that one.The HELP attribute text overrides any status-area text issued by the STATUS statement.
Back to the problem. In a trigger. Need to change the status display while a report is running. HELP attribute is being a bully. Changing the HELP attribute doesn't get displayed. STATUS DEFAULT only displays when a message from the running report gets displayed at the end. That is too late.
I am tired of playing all morning with what should be a simple task. Can it be done? Or do I have to hatchet the existing code, remove the HELP attributes and add a bunch of STATUS statements? Am I better off tearing up the code worse and making a pseudo status area at the bottom of the frame and having total control of my own status message var? How could this be so difficult and how could this not have been addressed yet in some thread here (he cried to the heavens...)
-----
Concerning the general question, am I asking too much from this forum? Is it too much to ask that Senior ProgressTalkers add to their long and definitive answers some warning that omitting a key fact or a slight change in environment will cause the situation to completely change and cause you to grind your gears for an afternoon trying to get their solution to work?
Progress is powerful. There are a multitude of options to give you more control. Every situation cannot be guessed by those trying to help. Yadda yadda yadda.
There have been too many times that I've been let down by the omission of warnings of some of the pitfalls. Other times, the answers have been so situational as to be useless as any kind of general solution.
For example, I am working on a dynamic query and updatable browse mega-utility. I understand enough to realize there can be no template for such a browse that would meet all needs (although when I'm done with mine, I'll have a nice template for viewing and updating parameter tables, but I digress). The point is it still shouldn't be brain surgery. I can't tell you how many times I've gone down a road based on advice from a thread here and had to backtrack and start a new path.
I can only get to screen values of the browse updates to validate before saving them by referencing the Screen-Value of the ColumnHandle ??? OK, Progress... But that means I need to define the browse in such a way as to store the column handles. Which means that formatting the columns needs to be handled outside of the browse definition. BUT, if you do it in the browse-row-display trigger, you'll have errors if you need to set the browse to Read-Only while validating, so the only way to do it is to manually format the fields in your temp table. So, you can't use LIKE to define your temp table and must manually define all the fields. Progress may be powerful, but they could use a few more methods to make having complete control over a browse stop being a convoluted nightmare.
AT LAST TO THE EXAMPLE. In trying to loop through the browse rows (so I could get at the screen values through the column handles), I needed to select the first row and then iterate through them, working on the modified ones. MORE THAN ONCE, ProgressTalkers suggest using the SELECT-ROW method in similar situations. Nowhere in all the examples I was looking at was it mentioned that this method only starts on the rows IN THE VIEWPORT. Thank god I caught it in testing, but it worked when I had the first row in the browse in sight, but skipped all records above when I was scrolled down a page or more.
Of course, it's in the reference help for the method (once at the beginning), but the help also states:
Gee, that part doesn't mention the KEY point of the position being IN THE VIEWPORT! Thanks Progress Help!Syntax
SELECT-ROW ( n )
n - An integer expression specifying the ordinal position of a row within the browse.
I didn't know whether to be more angry at ProgressTalk or Progress itself. Should their reference be clearer? Yes. Should they have a method (or at least an option in the current method) to select the first(!) row of a browse? Yes. If they want me to use the QueryHandle instead, they should have given me a way to access its Screen-Value.
Should ProgressTalk have already gone through this gauntlet? Yes. I mean, if ProgressTalk doesn't even have browses mastered, I'd be better served by praying for advice instead of looking it up.
I wonder if the knuckleheads using some variation of Select-Row(i) to iterate through their browses have realized their danger and simply not annotated their advice here, or do they luckily only use browses that don't scroll? Or maybe they have bugs in their code and swaths of browse rows are being ignored.
I am often wrong and am not too prideful to admit it. If this is all my misunderstanding, then I will apologize whole-heartedly. If not, where can I go for advice when my shop hasn't any relevant examples and it's too complicated for ProgressTalk to give a complete answer? Or am I doomed to reinvent the wheel all by myself every so often in dealing with the six-faced and three-hearted Progress when all I need is a good example to learn from?