|
02-20-2017, 02:14 AM
|
#1
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
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?
|
|
|
02-21-2017, 12:32 AM
|
#2
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,646
|
Maybe you will have to manually call the ShowCursor() Win32 API function?
|
|
|
02-21-2017, 01:04 AM
|
#3
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by Tale
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).
|
|
|
02-22-2017, 12:30 AM
|
#4
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,646
|
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
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.
|
|
|
02-22-2017, 10:25 AM
|
#5
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by Tale
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.
|
|
|
03-09-2017, 07:35 PM
|
#6
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
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.
|
|
|
03-13-2017, 12:44 AM
|
#7
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
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).
|
|
|
03-13-2017, 03:04 PM
|
#8
|
Human being with feelings
Join Date: May 2015
Location: Serbia
Posts: 654
|
Thanks for the report. I hope you will not go away from IPlug.
Did you checked if this is happening in other plugin formats?
|
|
|
03-13-2017, 03:15 PM
|
#9
|
Human being with feelings
Join Date: May 2015
Location: Serbia
Posts: 654
|
VST seams to be working properly.
|
|
|
03-13-2017, 05:32 PM
|
#10
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by Youlean
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.
|
|
|
09-14-2017, 09:04 AM
|
#11
|
Human being with feelings
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
|
did you solve this?
|
|
|
09-18-2017, 02:45 PM
|
#12
|
Human being with feelings
Join Date: Dec 2015
Posts: 331
|
Quote:
Originally Posted by olilarkin
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.
|
|
|
10-06-2017, 03:59 AM
|
#13
|
Human being with feelings
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
|
great it works, thanks!
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 08:58 AM.
|