Message Boxes "activate" the code?

[acumenprog]

I am a Progress programmer, exclusively programming in the NxTrend/Infor SX.e application. Because of this, I don't always know which quirks and questions are related to Progress itself, or to the development tools available in the AppBuilder (which apparently are quite different from pure Progress code). I have seen this problem numerous times and wanted to know if anyone had some input.
Sometimes, I look at a piece of code that is not working, and I absolutely cannot find a problem in the code. So I start putting in messages so I can follow where the code is going. Eventually I isolate the part that is being skipped, even though I think that from reading the code, it shouldn't be. So then I put messages between almost every line, sending values to the screen, etc., so I can pinpoint exactly where the program is finding the problem. At that point, all the messages show (meaning every line is being read, none skipped)... and voila! the program works! It's almost as if it wasn't able to "see" that the code was there until I put in the messages, but know it realizes, so it runs that portion. This "memory of code" then sticks, even after I remove all the messages -- no changes at all to the "before" and "after" code, but the "after" code works. This is so frustrating, because you naturally assume that something is wrong with your code, so you can spend hours trying to fix it before you discover that you need "that message trick" again.
Does anybody know why this happens, and if there is a way to avoid it?
Thanks!

 

[lloydt]

I can't promise this will help your cause, but it's what I've experienced along the way. It's kind of complex for me to explain so I apologize if it's a little foggy.

I've found that that kind of thing happens because there are events that either walk on each other or an event or some piece of code is running that effectively makes something look like it's not working. An example would be an event procedure as follows that sets a screen value for a text box.

procedure SOME EVENT:
def input parameter iptxt as char no-undo.
fTextBox:screen-value = iptxt.
end procedure.

Most likely not an event you'd see anywhere, but for the sake of this topic, assume the procedure is an event. If that input value is text it appears to work, but if that input value is ? (null), the screen-value happily goes blank and appears to not work because you expected something there. If that event fires in succession with the last value being null, it appears to not work. Since it's event driven, the message can go pretty much anywhere in your code and possibly affect it. Adding the message may go so far as to stop the null passing event from happening, or it may show the application as working and then breaking depending on if the ui refreshes. The explanation usually lies in the code, and the bugger is tracing through the code to find the explanation and ultimately the cause.

If you are running a windows gui app that utilizes adm or adm2 <> there is a lot of event / trigger activity within those frameworks that is visible if you debug the application. For me, it's always turned out to be event related and caused by utilizing events in the code. Some adm2 events can be "overridden" to handle what you want the app to do, but the base events still fire, and they happily pass null around.

If possible, I suggest removing the messages and going in with the debugger and stepping through the code that you think may be causing the issue. It can be a lot more involved than just plugging messages, but the debugger is pretty useful.

Good Luck

--Lloyd

 

[acumenprog]

I am not sure I thoroughly understand your answer, so I am going to give you my exact example and you can clarify how it might happen here. I was looping through a table, gathering old information (specifically old prices), building a comma-delimited string with that information, and then displaying it in a combo-box after all data had been gathered. Sometimes, it displayed, and other times (for very specific customer/price combinations -- always the same ones every time), it didn't display. I tested out what was being gathered by putting messages to display the string values. When I got down to the nitty-gritty and put messages each time something was added to the string, there was always a valid addition. Finally, it worked (even though no changes other than putting the messages) and then I took out all the messages, and it still worked! I don't see where a null value could have come into play over there. (Before I had all the messages in, I just had "before for each loop" and "after for each loop", and it's possible that the string value that was outputted to the screen in the "after" message was something like null or blank, which seems to support your theory of the message box blocking a null value from passing, but that's the part I didn't really understand so well). By the way, I am not familiar with the Debugger (may sound crazy for a programmer, but none of us use any sort of debugger to go through our code) -- how do I use it?

Thanks!

 

[lloydt]

I am not sure I thoroughly understand your answer

I apologize, I didn't know the context of your situation from your previous post and was posting generic response.

I was looping through a table, gathering old information (specifically old prices), building a comma-delimited string with that information, and then displaying it in a combo-box after all data had been gathered. Sometimes, it displayed, and other times (for very specific customer/price combinations -- always the same ones every time), it didn't display. I tested out what was being gathered by putting messages to display the string values. When I got down to the nitty-gritty and put messages each time something was added to the string, there was always a valid addition. Finally, it worked (even though no changes other than putting the messages) and then I took out all the messages, and it still worked! I don't see where a null value could have come into play over there.

Without seeing the code (sounds straightforward enough) I've got a few guesses as to the cause. First, if you are compiling to .R code, I have run into similar situations where the .r code doesn't generate correctly for whatever reason. Sometimes inserting the messages as you said you did apparently affects the .r code enough so that it clears up and it just works. Other times, I have to close the entire appbuilder / prowin32 session and restart it, recompile and then try. Sometimes it's as simple as deleting the .R file and recompiling. I can't explain why, nor can I catch enough details to report it to Progress support.

Another possible scenario is the gui screen refreshes. Take for example a fill-in widget called ftxtbox. Setting the SCREEN-VALUE attribute of ftxtbox will affect the gui but not necessarily the data field, whereas setting the ftxtbox value directly may not affect the gui unless you follow it with a display statement like "display ftxtbox with frame {&frame-name}". Off the top of my head I don't know if that same thing holds true for a combo-box or not.

The other thing you could try in similar situations is to output to a file and use the export statement. The display statement can sometime produce wierd results in debugging because of the way it does paging, etc. Not sure this would have applied to your situation though.

(Before I had all the messages in, I just had "before for each loop" and "after for each loop", and it's possible that the string value that was outputted to the screen in the "after" message was something like null or blank, which seems to support your theory of the message box blocking a null value from passing, but that's the part I didn't really understand so well).

The whole null value thing won't apply in your situation, again I apologize.

By the way, I am not familiar with the Debugger (may sound crazy for a programmer, but none of us use any sort of debugger to go through our code) -- how do I use it?

There are a couple ways to use it, I usually bring up a client window, type in the run statement for my program and hit shift-f4 to start the debugger (debugger option on the compile menu). from there it's a matter of break points, stepping through code, and monitoring the data on the bottom panes. It's also possible to initiate the debugger from within your code useing the DEBUGGER system handle, for an example on that search on Debugger system handle in progress help. There may also be some tutorials on psdn.com on how to utilize the debugger.

Regards
--Lloyd

 

[MrMoo]

I ran into a similar issue with Oracle Form Builder when I was co-oping in University. The message fix worked, never figured out why but it was a pain at times, trying to figure out what was wrong and suddenly it runs fine with no code change but the messages added.