Getting 'Not Currently In A Callback' during a callback

I've been getting some of these when the callback processing function is tied to a %tx control.

I've been tagging and tracing these, getting the result from the CLEARWIN_STRING@. Sometimes, I'll get these when depressing the left mouse. Sometimes, when moving the mouse over the control.

I've never had a keypress fail to get recognized as a character being input.

My question is: Can I get the actual message value, rather than just the string?

It will be helpful to find what is initiating a call back whose string value says no call back was in progress.

I can't see this message within ClearWin+ so I wonder if it is being generated elsewhere.

If you have not already done so, you should consider called permit_another_callback@.

I guess that you are using 'CALLBACK_REASON'. The 'WM_' message number is not available directly but you might be able to get further information by either a) using %mg with a callback return value that allows processing to continue and/or b) a Windows 'Spy' application such as the one provided by Microsoft.

Apologies: The message is the return value of '?'.

Have you tried using permit_another_callback@?

No, I haven't. If I were to use this function, do you think it would help? I do use a TEMPORARY_YIELD@ in this window normally, so I think this underlying requirement may be met.

I do not see any examples of where one would use this, either on initial window creation, or within a loop, or within an existing callback function.

Point me in the right direction and I'll give it a go!

I do not see any examples of where one would use this, either on initial window creation, or within a loop, or within an existing callback function.

Point me in the right direction and I'll give it a go!

As an FYI, I looked at the window handle generating these events, and even though the window does NOT have focus, things like mouse movements will cause the '?' as the CLEARWIN_STRING@ return.

I checked the CLEARWIN_INFO@(CALL_BACK_WINDOW) with the handle of the %tx window (which does NOT have focus, but is visible).

As a first step try calling PERMIT_ANOTHER_CALLBACK@() from within your %tx callback function. Let me know if this makes any difference.

I ran two scenarios.

First, I placed the call at the end (return) of the callback function. Second, I placed it at the beginning of the callback function before any messages had been retrieved for processing.

The results are the same; I'm still getting '?' responses whether or not the %tx window has focus in response to mouse moves; clicking the left button SOMETIMES generates a '?' along with the proper response (sometimes before, usually after); sometimes, clicking the left mouse button does not generate a MOUSE_LEFT_CLICK, it generates a '?'.

I don't think that it matters where you make the call within the callback.

Try leaving it in and also call PERMIT_CALLBACK_IN_WINDOW@(hwnd) where hwnd is the %hw value for the main window.

After that I am stuck.

On that last part (PERMIT_CALLBACK_IN_WINDOW), should I restrict its call to only when that window has focus?

I'll try it in any case.

One thing that did happen after my last message; since I have tracing on, I got an attempt to perform I/O while performing I/O fault. I suspect that processing the callback, then getting another callback may have done this. I will attempt to find another tracing solution.

Initially I would not restrict the call. The overhead is probably very small. If it works then you can refine it later.

I've tried the calls separately, together, at the start and at the end of the %tx callback, and there is no change.

Stuck, perhaps. Defeated, no.

If I come up with a solution, or a more definite result, I'll let you know.

I removed the FULL_MOUSE_INPUT from the %tx creation and achieved a better (in some ways) result. Here's a list of what happened:

No more '?''s when moving the cursor around; No more missing left mouse clicks; No more '?''s when pressing the left mouse button, but No detection of MOUSE_DOUBLE_CLICK. MOUSE_LEFT_RELEASE works for a mouse click, and the %tx control coordinates are correct;

Not getting any MOUSE_MOVE messages negates one utility function, but if the mouse clicks are now reliable, it is a reasonable trade-off.

I'll continue to play with this to see what I can get functional again.