TOPIC:

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.

Dick

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).

Any thoughts are appreciated.

Dick

Hi Dick,

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.

Sorry I can't be more helpful.

Regards,
Tim

Hi Dick,

Just a thought. Is the rogue Windows machine a virtual machine? If so, how many processors are allocated to it?


Regards,
Tim

Hello Tim,

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.

Dick

Hello Dick,
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.

Terry

Hello Terry,

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.

But it remains an unsatisfactory solution.

Dick

Hi Dick

Understood, and as you said at the start - a problem that makes no sense at all.

I've no logical reason for suggesting this, but could it be some timing difference on your client's machine?

Ideas exhausted.

Terry

Dick,

How did you code your ErrorBox?

Is the owner specified? If the owner is specified, which window is the owner of the ErrorBox?

Jamal

Hello Jamal, Terry,

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:=SelectMailInfo{SELF,""}
oSelectMailInfo:SetDefaultModel("MAILINVATT",TRUE)
oSelectMailInfo:Show()

ENDIF

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.

Not sure if this gives a clue to anyone

Dick

Dick,

Is the Type of the DialogWindow set to Popup Dialog and Modeless set to True?

Jamal

Hello Dick

On further thought this does make some sense.

Realistically I think you have done all you can to mitigate the problem.

FWIW my reasoning is as follows:

You will remember you said that years ago you felt you understood how your pc worked, but not any longer.

At that time the pc was working more or less like a glorified calculator. Basic maths: +, - etc. Effectively operating in the x/y plane.

As things have advanced, we can now consider the electronics to be operating in the 3 dimensions of our real world: x, y, z planes.

Calculations in the z plane are essentially imaginary (see Jack & Beanstalk for logic of conversion to projections on x,y plane).

These imaginary calculations correspond to the Air Traffic separation in J&B Model.

By introducing a new Dialog Window you are essentially interrupting logic on the x, y plane. This makes no difference to the logic on the z plane which behaves exactly as before.

The logic on the z plane is not under the control of your program. It is in fact controlled by the Operating System (switching between threads).

These are just my first thoughts - others may have other ideas, or could perhaps take this further, by upping thread priorities or similar.

Terry

Hello Jamal, Terry,

I did not reply to your question, no it's not modeless. It just starts failing with any existing dialog in my program which works elsewhere. And again: only for this client & even with an old exe version which used to work perfectly...

I now skip the dialog for this client -hard programmed- as they will always make the same choice from the dialog anyway. If I find out more in the future I will let you know.

Dick