Random errors: what can cause them

Focus problem:
Building a beautiful and modern UI, with lots of panels/windows interacting with each other can become a nightmare really incredible... Of course, in that case, you have a lot of events firing, because you want to do some special things when resizing, when right clicking, and so on...

Well if you want to play with that kind of things, you'd better keep in mind that just knowing what window has the focus can become a very difficult task... Imagine some of your code running and at the same time the user click on another window...
- When does the focus leave your previous window?
- Do you have any multitask somewhere in your code that will let another code execute during this time?

So, if everything works well in test mode, but the behavior in executable mode is totally different (or the contrary), and of course, if you run your code in the debugger, everything is perfect, then there is a great chance that you have a focus problem...

If you use the debugger, your debug window is stealing the focus anyway, therefore don't expect any result for debugging that way...

If you do a TRACE, an info, or any other kind of display, you are ALSO changing the focus management. Isn't it great when as soon as you display anything in the trace window, everything works fine?

How do you solve this kind of problem?

- First, you verify your code: you should NEVER rely on instructions like WinInput/FenEnExecution in complex UI. You can generally use them during the window initialization to get the window alias, but you should store that information and use it everywhere else. WinInput gives you the window currently having the FOCUS, even if you are executing a code in another window (WinDev 5.5 behavior, not tested in 7/8/9)

- Another NO-NO is to access the window field by the field name alone... Always use the WindowAlias.FieldName syntax... If your UI uses the same window several times, you'll be happy to see the current field being used.

- Finally, never suppose that a window HAS the focus at any given time... Give the focus explicitly to the window who needs it in your code logic... And DON'T put any code in the gain focus/loose focus sections of your windows... If you do, you can end up with bad loops going on in a complex UI...

- Basically, if you are planning on building such a complex UI, you should manage everything from the outside, in a manager class by example, and NOT rely on the code in each window being executed by events. If you choose that last method, you will depend on your events being executed or not, and you will never be sure of when the code is executed, and how many times...

Finally, how do you debug this kind of problems? We already saw that the debugger is out, and so are trace and info windows... The first thing you can try is to have a second executable that will display the information instead of your main one, solving the internal focus stealing problem. If you do that by message and shared memory, you end up with your main program waiting for the secondary one to do the display, introducing delays that WILL change your UI behavior (events being fired before or after, etc...).

Remains only the old 'write in a file/read from the file method'... You still need an external EXE to read from a trace file and display your debug info, but in your main program, you just need to write debug lines in a direct file, without waiting for anything. Of course the resulting trace display is asynchronous, and writing in a file will slightly slow down your program, but it's the best solution for this kind of problems.