COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 02-20-2017, 02:14 AM   #1
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default Mouse cursor vs text editing, Win

I have a text edit field that inherits from ICaptionControl. It works fine on Mac. On Windows (10, 64-bit, VS2015, AAX), the cursor goes away when I start typing, as expected, but doesn't come back till I move the mouse so that the cursor is outside of the plugin window.

Expected behavior:

• cursor disappears upon typing
• cursor re-appears when mouse is moved

This is normal for any text field. It's the way this webpage works. It work this way for my Mac build.

On my Win build, I need to move the mouse a couple of inches to get the cursor to re-appear, outside of the plugin window.

Ideas?
earlevel is offline   Reply With Quote
Old 02-21-2017, 12:32 AM   #2
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Maybe you will have to manually call the ShowCursor() Win32 API function?
Tale is online now   Reply With Quote
Old 02-21-2017, 01:04 AM   #3
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by Tale View Post
Maybe you will have to manually call the ShowCursor() Win32 API function?
I did try that, no success. In IGraphicsWin::WndProc, after edit completion, both pGraphics->ShowMouseCursor() and ShowCursor(true).
earlevel is offline   Reply With Quote
Old 02-22-2017, 12:30 AM   #4
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Then maybe the window doesn't have a mouse cursor associated with it? I seem to remember you can assign a specific mouse cursor to a window (i.e. an actual window, or a button, etc.). Then Windows will automatically set that cursor when the mouse moved into that window.

Quote:
Originally Posted by earlevel View Post
This is normal for any text field. It's the way this webpage works.
Well, this website maybe, but it's not normal as in default behavior.
Tale is online now   Reply With Quote
Old 02-22-2017, 10:25 AM   #5
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by Tale View Post
Well, this website maybe, but it's not normal as in default behavior.
?? Normal behavior for a text field on Mac OS and Windows is to hide the cursor once typing begins, and un-hide it when the mouse is moved. That's what I'm expecting here.
earlevel is offline   Reply With Quote
Old 03-09-2017, 07:35 PM   #6
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Got back to this problem last night...proving to be a difficult debug...

I have two value-edit fields on my plugin. On the Mac, they behave exactly as expected. On Windows, the mouse cursor hides as soon as input from ascii keyboard starts (expected), but it does not unhide as soon as the mouse is moved. I have to move the mouse far, and it re-appears as soon as it's outside of the plugin window.

I've stepped the code, and it looks like the standard Windows calls to pop up a child window for editing is working as expected. Except that the mouse cursor behavior seems to be masked by the plugin window.

My text field control is an enhanced ICaptionControl. But I've substituted a plain ICaptionControl and the behavior is the same.

However, if I use ICaptionControl (or my control) in a bare-bones plugin (modifying the IPlugControls example), it has the expected mouse behavior—works fine.

As far as I can see, IPlug/wdl is not handling the mouse cursor behavior, Windows is. It seems something has messed with the mouse area it's masking to—the whole plugin window instead of the field. Unfortunately, Windows documentation doesn't spell out any details of the mouse behavior—because it's just the way Windows copied Mac from day one.
earlevel is offline   Reply With Quote
Old 03-13-2017, 12:44 AM   #7
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

I removing things till my whole AAX plugin simply has one parameter, controlled by an ICaptionControl. No, audio processing, just the plugin constructor—no other code overridden. MakeGraphics, param->InitDouble, AttachPanelBackground, new ICaptionControl, ->Disable Prompt(false) it so it's editable, AttachControl, AttachGraphics. That's the entire plugin. It still has the bad cursor behavior under Windows.

I build it as an app—the proper cursor behavior.

So, it's either the Plug AAX code (or something it's not doing), or Pro Tools (unlikely).

Avid plugins that come with PT don't have the bad behavior. However, they don't have the standard behavior either—the mouse arrow pointer is always live, even while editing a text field. That's not necessarily key to the problem, though, since Avid plugin also have the same non-standard behavior on Mac, while my plugin's behavior is correct/standard on Mac, broken only in Windows.

Anyway, just wanted to update that in case one of the few AAX developers have run into this before with IPlug and Windows. Or more likely just a note for posterity if I have to give up on IPlug. Not planning on it, since the plugin otherwise is complete (and shipping on Mac).
earlevel is offline   Reply With Quote
Old 03-13-2017, 03:04 PM   #8
Youlean
Human being with feelings
 
Youlean's Avatar
 
Join Date: May 2015
Location: Serbia
Posts: 654
Default

Thanks for the report. I hope you will not go away from IPlug.
Did you checked if this is happening in other plugin formats?
Youlean is offline   Reply With Quote
Old 03-13-2017, 03:15 PM   #9
Youlean
Human being with feelings
 
Youlean's Avatar
 
Join Date: May 2015
Location: Serbia
Posts: 654
Default

VST seams to be working properly.
Youlean is offline   Reply With Quote
Old 03-13-2017, 05:32 PM   #10
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by Youlean View Post
VST seams to be working properly.
Thanks for checking VST. I had only checked as standalone.

I also verified that Avid's plugins behave the same on MacOS and Windows. Their behavior is non-standard—the cursor never hides—but consistent. I've eliminated enough possibilities that I put the question to someone at Avid today, waiting to hear back.
earlevel is offline   Reply With Quote
Old 09-14-2017, 09:04 AM   #11
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

did you solve this?
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Old 09-18-2017, 02:45 PM   #12
earlevel
Human being with feelings
 
Join Date: Dec 2015
Posts: 331
Default

Quote:
Originally Posted by olilarkin View Post
did you solve this?
In IGraphicsWin::WndProc, I force the cursor arrow:

Code:
    case WM_TIMER:
    {
      if (wParam == IPLUG_TIMER_ID)
      {
        //### added this: ###
        // if cursor is null, force arrow
        if (!GetCursor())
          SetCursor(LoadCursor(NULL, IDC_ARROW));
Ugly, possible to flicker now and then, but I noticed Avid's own sample native AAX plugins force the cursor to arrow (somehow—didn't try to figure it out) and flicker too. Wasn't going to spend a lot of time on this—Pro Tools appears to be handling the cursor wrong. Avid acknowledged the goofy behavior, didn't have an answer.
earlevel is offline   Reply With Quote
Old 10-06-2017, 03:59 AM   #13
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

great it works, thanks!
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 01:17 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.