After the said update, I started seeing instances, where some of the entry control would not show text as I type. It will not show the blinking cursor either. When I tab out, the already typed text would appear. But, it would do exactly the same on the control onto which the focus has now moved into. This does not happen on all the window but always happens on same window.
Other observations:
If I move the window using the title bar OR press the ALT key, this problem goes away. (It would happen again, the next time I start the application again).
It gives the impression that, there an invisible window on top and it could be taking over the focus.
One of my window has an automatic 5 minutes autoclose timer. This timer text is update in the windows timer event. The bizzare part is, it doesnât refreshes the timer text at all. But, as soon as I move the window using the title bar or press ALT key, everything would works fine as expected.
I reverted my Windows to the previous build (1607) and everything would worked fine as normal.
This is not an isolated incident on 1 or 2 PCs. Nearly all the PC we have updated to Windows 10 1703 has this issue. Infact, it was reported to us by some of our clients.
I am in the process of isolating this issue by logging, debugging, and also removing 3rd party templates one at a time. But, so far without any success.
Is there anything anybody could think of, please suggest. I am very desparate to get to the bottom of this as this new update is being forced onto the PCs and there is not opting out feature available anymore.
Iâve not seen your problems but Creatorâs is causing problems for me on my C6 app.
Weâve seen it on multiple PCâs. Weâve also been able to a working Windows 10 PC and install Creatorâs and then have a broken app.
My problems relate to the print previewer (TinTools). It pauses during report generation and then only resumes when you wiggle the mouse. Also once you have the preview on the screen, click it to zoom in and out has no effect. This can be resolved by minimising and then restoring the window but Iâm obviously not going to be able to tell my clients that!
Did you try press the ALT key when it pauses during the report generation? Also, on my application, if I keep the mouse clicked (IE keep it pressed for 2 second atleast) it would work.
In my case it looks like there is a hidden window (like a popup menu) somewhere that is taking the focus away from the main window.
NOTE: I get the same issue in C10 compiled app as well.
Looks like we are on the same boat to an extent. I also noticed on my application, that when I hover the mouse over entry control, the cursor doesnât change to âIâ and remain as a pointer. As soon as I press the alt key, everything works normal. This goes on to prove that the window in question is losing the focus.
I wonder if its the LIFO/FIFO event processing I have seen which is causing the problem, you get random hangs with this, and its more noticable with some events than others.
Your only way of testing for this is to use debugview, the clarion debugger wont show it as it only processes one thread at a time, where as debugview can accept messages from all threads as they happen.
This approach works with my app also to an extent. The issue with me is, I have come across a few windows that has this issue. There could be several more. If, I add the code the an existing window without the above mentioned focus issue (may be using a new template to add it to all the windows), it will auto-close as soon as the window is opened.
also, on the problem windows, if the user clicks OR press alt before the above mentioned code (F10, EscKey), then it will receive the focus, then your code will ESCAPE close the window.
I had pretty much the exact symptoms just recently!
In my case, it seemed to be connected to opening a child window too early in the main frame threads startup code.
Frame thread loads
In ThisWindow.Init there was a call to a WindowProcedure (a login window as it happens).
That login window was behaving as you describe.
The login window was not firing events at all after it opened until you âactivatedâ it somehow. By moving it or possible lose/gain focus. I canât remember exactly.
My fix was to delay the calling of this window until later, the theory being that would allow the main frame to fully open in whatever way it need, and to also start the login window on a new thread rather than directly on the main frames thread. This also required a different approach in order to retain the âyou can do anything until you have logged inâ requirement.
The issue I had was not just on the Application Frame. It happen even before the MDI Frame procedure was called. It was happening on the LoginScreen procedure, which was a non -mdi child window. It ALSO happened on the MDI window (Application Frame) and also on some of the other windows launched from Application Fame.
I have even called a dummy window instead of the login screen with no code at all in it. Even the dummy window procedure showed the issue. This proved, in my case, that is was not a code related issue. The approach I (as explained) seemed to have fixed all the issuesâŚ
The problem seems to have resurfaced again for my application. But, this time I think I found the culprit. In Windows 10 there is this option under Printers & Scanners called Lets Windows Manage my default printer. See image below:
With this option ticked, whenever the first time my application try to do a PRINTER{PROPPRINT:Device} = âMy Whatever Printerâ, it would cause the window to lose focus and it actually prevented the entire ACCEPT loop from properly function. This can be resolved by press the ALT key once or move the window using the titlebar, and thereafter everything would be fine for that session.
I also found, as soon as your application opens, if you open the printer dialog box and even cancel out of it, the application would work find thereafter for that session.
I do not have a resolution yet that I can implement within my application to resolve this. The work around I have for now is to Untick the above mentioned option within Printers & Scanners.
Old topic and hard to detect bug.
When a no FRAME window that has no menu, like a login screen, and the user press Esckey to close it, that triggers a Clarion Bug in runtime that makes âstrangeâ application behavior.
Solution for my case is to press F10 before close the window by Esckey event (I assume that F10 key âoilsâ the âphantomâ menu window event???):
Open(WinLogon)
0{Prop:Alrt,255} = EscKey !If not defined in Window Block.
ACCEPT !Event handler
CASE FIELD()
OF 0 !Handle Field-independent events
CASE EVENT()
OF EVENT:PreAlertKey
IF KEYCODE() = EscKey
PRESSKEY(F10Key) !Press F10 before window close
POST(EVENT:CloseWindow)
CYCLE
END
