Sometimes we run into a problem with VO which does not make sense at all - and this is one of these.
We have a DataDialog with a bBrowser on it showing content of a bArrayBrowser. Users can select one or more invoices from the bBrowser from which an e-mail is created with the invoice attached.
Without a change in program one user suddenly saw the program did not create the e-mail anymore. Further investigation showed that an errorbox was displayed that no selection was made in the bBrowser although it was. Remarkable thing was that this errorbox was only visible after closing both the DataDialog with the bBrowser on it and the DataWIndow from which the DataDialog was called.
Finally we found that opening a DialogWindow (which was displayed to let the user select a mail model to be used) caused the problem. I thought it may have been something to do with HoverButtons on that. However recreating the otherwise very standard selection window as a normal dialogwindow did not help either.
I also tried to keep the bBrowser selection and re-assign it after showing the dialog en setting the focus to the DataDialog window with that bBrowser on it. But still the selection was not recognized. The method we use for that has worked for ages and basically is using SelectionRowCount and SelectionNextRow to read and store recordnumbers or field values of the selected elements.
Note again that nothing was changed in the program when this simple "ages old" code was running and also that it works perfectly on any other Pc; the same program runs for most of our clients. I suspect one or another WIndows update may be the only changed factor, but how could this invalidate reading bBrowser array records after opening a simple dialogwindow?
Maybe someone has seen something similar which can help me to explain - and solve it.
I rephrase this question to what I think is the core issue, as I did not get any reactions.
When I open any window within a method invoked from a DataDialog window, the execution of code appears to stop somewhere. Most visible is that an appearing errorbox shows up behind the datadialog (and the datawindow from which the datadialog was opened). This happens also on older unchanged exe's where it used to work for that client. The same (new and old) exe works fine everywhere else.
Can someone explain why a normal Errorbox program line does execute but either shows the errorbox behind the other open windows, or (maybe more likely) only executes AFTER I closed the windows? Then it shows and of course anything else following in the code where it relies on the datadialog (which is now closed) will fail (and often crashed the program).
I have seen different Windows machines do some really exciting things for no logical reason. The DotNet frameworks have helped enormously in minimising these problems.
If it happened on every installation, I would suggest you check the owner of the window screens.
Don't know if this helps, but I was compiling my main app in Vulcan until recently. All was fine until one day the program would produce an unexplained error. Recompiling from scratch fixed it for a while, but it got to the stage where the app was unusable. Going to XSharp solved the problem.
Thanks for your reply. Yes, it is a Hyper-V machine. The main problem is however that the program did not show that problem before on the same machine; it occurred out of the blue, also with older exe version. And the very same program did not have that issue on any of the other installations anywhere.
Hence, in some respect it doesn't make sense to try to find the solution in the code, but on the other hand, the issue is clearly related to including opening a windows like a dialog box in that method.
I don’t know if it the following will prove useful, but it may help to look at this from a different perspective. In my “Jack and the Beanstalk” post I was trying to justify the fact that we may think of a running program in just the same way as we think about doing things in real-life.
I would suggest you try that approach here. Your program has a huge, but finite, number of roads linking things together. This road system has been defined by the programmer. In operation the exact route followed from program start to program end (input to output) is dictated by the user. (who may go around in circles if he wishes!)
If something has changed anywhere in that input output route, or the user has simply taken a different route, then an anomaly could propagate through to the output.
That is what I think has happened here. The fact that you get an error box seems to indicate that such an anomaly is correctly detected.
In order to identify where the problem may lie, I would try to think logically “backwards” form the final output.
Clearly the alternative routes grow quickly and manually you won’t be able to go very far back. But the fact that you have relatively few customers experiencing problems points to the fact that the problem is likely to be close to the end point.
Using the roads analogy also allows you to fairly easily think across to code. For example, one-way streets could map across to code in terms of getters and setters.
I hope this makes some sense.
Thank you for your thoughts. The method in where it goes wrong is very straightforward and doesn't give the user any alternative way of running the code. In summary:
1 The behavior (that the programs seems to stop following the normal code and/or later messages are hidden behind the windows (or postponed until these are closed) can clearly be pinpointed to (just) opening any dialogwindow in that method.
2 Doing the exact same steps with even the same data in my system does work fine
3 That method works fine in every other system
4 It did work fine on this client's system until recently. Now it fails, doing the same there, even doing that with an old exe which used to work.
I'd say then it must be something environmental. But there have been no recent Windows updates. I think the only thing which may fix it is if someone recognizes the situation and found a cause in some setting. There's only a small chance someone has.... I have now removed the code opening dialog in the procedure for this client only as I know they will always make the same choice from that dialog and this choice is now hard programmed.
Timing difference is an interesting suggestion. I can try uploading a version where I delay displaying the window to see if that makes a difference.
This is the code:
IF (Added condition that it displays for all users except the one where it goes wrong)
oSelectMailInfo is a Dialogwindow. I tried Datadialog as well, both our inherited class and the default VO class. I also tried multiple other windows from my program but displaying any window causes the problem.
SELF: is a datadialog window. This is displayed from a Datawindow.