InputText Bug(?)

[exper1mental]

Recently I noticed that I often have to send 2-3 execute batch bangs to InputText plugin measures before I get an input box and can type anything in. The chance of it working versus not working seems to be completely random as far as I can tell.

The times the execute batch bangs do not work I get the following error:
InputText: Exception System.ObjectDisposedException: Cannot access a disposed object.Object name: 'InputBox'.

This is with Windows 8.1 Pro 64-bit and Rainmeter 3.2.1.

Any idea what's going on?
Thanks

[jsmorley]

No idea. I have never seen that, and I can just hammer an InputText measure with no problem ever.

I'd like to see a .rmskin of a skin that does that for you.

[exper1mental]

No idea. I have never seen that, and I can just hammer an InputText measure with no problem ever.

I'd like to see a .rmskin of a skin that does that for you.

Ok, I've uploaded the skin I'm working on that is having the issue.
Download from Sta.sh ~ 3.1 MB

It is this skin and one other on my computer that seem to be affected, all the others that use InputText work fine.

[jsmorley]

I get the same error with that skin. I'm not sure exactly, but I suspect it has to do either with the fade "transition" you are doing, or more likely, with all the hiding and showing of meters you are doing. I suspect you are getting a "mouse off" event registering while the InputText plugin is still trying to get set up. Somehow this is causing it to try to access an "object" that it has already "destroyed". An InputText box needs to get and keep "focus" while it is being used.

FocusDismiss=0 on the measure fixes it. That is a big hint. I really think having an action that causes the plugin to lose "focus" in the same action that is executing the plugin is going to cause issues. It's like it is trying to both "create" and "destroy" the plugin instance at the same time.

I'd try to simplify that a bit if it were me.

[exper1mental]

I get the same error with that skin. I'm not sure exactly, but I suspect it has to do either with the fade "transition" you are doing, or more likely, with all the hiding and showing of meters you are doing. I suspect you are getting a "mouse off" event registering while the InputText plugin is still trying to get set up. Somehow this is causing it to try to access an "object" that it has already "destroyed". An InputText box needs to get and keep "focus" while it is being used.

FocusDismiss=0 on the measure fixes it. That is a big hint. I really think having an action that causes the plugin to lose "focus" in the same action that is executing the plugin is going to cause issues. It's like it is trying to both "create" and "destroy" the plugin instance at the same time.

I'd try to simplify that a bit if it were me.

Hmm... I stripped the skin down to the search component and I still get the problem unless FocusDismiss=0.

Input Text Bug.rmskin

Just for kicks I tried changing the skin from being topmost to normal and viola! InputText works beautifully with FocusDismiss=1. All the skins I've encountered the issue with were in Topmost or Stay Topmost positions with FocusDismiss=1. If I right-click and change them to Normal, Bottom, or On Desktop the problem disappears. Why does this work?


Also, if FocusDismiss=1 and then I close a skin while its Input Text box is open (like by clicking the exit button in the previous skin), Rainmeter locks up and crashes.

If FocusDismiss=0 and then I switch to a different skin in the same path, the Input Text box closes and everything works fine. However, if FocusDismiss=0 and I then close the skin in Manage, the Manage window locks up and must be closed, but the Input Text box closes and the rest of Rainmeter does not lock up or crash.

[jsmorley]

Well, the long and the short of it is just a function of what InputText is. It isn't a "meter" in the skin, but is an entirely separate, floating, self-contained Windows input field.

It must have mouse focus to work. While it is "running", it will not allow any other mouse clicks in the skin. The skin is in effect "locked" while you are doing the input. However, I think you can fool it with MouseOver, and that is going to be bad.

The text you type in is captured and returned to the skin when you hit Enter.

If FocusDismiss=1, (default) then clicking anywhere else will cause the plugin to dismiss the input text field and exit. If FocusDismiss=0, then only ESC will do so.

Having said that, FocusDismiss=0 is really a bad idea. It means that once "running", it is possible to have another another window, another skin, OR EVEN the same skin that created the input field be put "in front of" the input box, effectively blocking the field from the mouse. This is going to have undesirable results.

It also means that since the field isn't dismissed without ESC being hit, you can actually close the skin while the input field is open, which is going to be fatal. You now have a Windows "control" on the screen that is entirely dependent on a parent application (that instance of the InputText plugin) that no longer exists, and that is inherently unstable. Rainmeter crashing is quite likely.

So the answer is to use InputText carefully.

Never use it in a skin set to "Stay topmost". (and I am leery of "Topmost") That is likely to cause the skin to "jump in front of" the open InputText box. Remember, the input field is NOT PART OF THE SKIN. It is a separate entity entirely in Windows.

If FocusDismiss=1 that will cause the InputText field to lose "focus" and dismiss when you don't want it to, and if FocusDismiss=0 you can end up with the skin all locked up and at risk of crashing Rainmeter.

InputText is actually terrible in my view. It does what it needs to do, and if used very gently is quite useful. However, don't push your luck with it. It needs to be "in front", it needs to be FocusDismiss=1, it should not have any meters or skins that can be "unhidden", "made solid", "moved" or otherwise made to get in front of it.

Here is how I use it.

Create a meter to be the "trigger", that will have the mouse actions on it. Logically it makes sense to have this meter look like the InputText field you will create, so there is a reasonably seamless transition from the "meter" to the "input field".

After mouse click, the meter(s) are "behind" the InputText field. In this example the InputText field is just slightly smaller than the "trigger" meter, so the "border" on that mater still shows.

Then you type your text, and either hit Enter, or click away or hit ESC to dismiss:

test.gif

[eclectic-tech]

Some additional cautions I have experienced regarding InputText measures in skins that also have bangs to refresh the config.

I experienced a similar phantom crashing issue on an InputText skin that also used mouse scroll bangs that used !WriteKeyValue and !Refresh bangs in the [Rainmeter] section; nothing to do with the Z-Position settings.

While the InputText box was active, if the Mouse Scroll bangs fired, Rainmeter would crash (stop responding to any actions) and have to be killed and restarted.

If I remember correctly the error log had an identical error message as exper1mental posted.

This is a multi-search-engine skin, scrolling the mouse changed the search engine, so I did not want to eliminate that feature.

My option is to warn in a Tooltip NOT to change engines while the text box is active.

I don't think there is a solution due to the external nature of the InputText operation as JSMorley explained. I guess caution and simplicity are the best solutions when using this plugin.

[jsmorley]

You are right eclectic-tech, a mouse scroll combined with a !Refresh is a sure way to crash things with InputText if it is "open" when you scroll. MouseOver and MouseScroll don't impact "focus", so those are dangerous if you do something that "orphans" the InputText field while it is running.

[exper1mental]

Well, the long and the short of it is just a function of what InputText is. It isn't a "meter" in the skin, but is an entirely separate, floating, self-contained Windows input field.

It must have mouse focus to work. While it is "running", it will not allow any other mouse clicks in the skin. The skin is in effect "locked" while you are doing the input.

Unless I use FocusDismiss=0 I don't get the skin "lock" you are talking about. Mouse actions still work. They close the box but it seems they execute their bangs first, otherwise clicking on the exit button that closes the skin wouldn't also crash Rainmeter.

I can fix that issue easily enough by disabling the button when the InputText is open, I'm just trying to understand whether or not I'm seeing the behavior you are talking about.

The text you type in is captured and returned to the skin when you hit Enter.

If FocusDismiss=1, (default) then clicking anywhere else will cause the plugin to dismiss the input text field and exit. If FocusDismiss=0, then only ESC will do so.

Having said that, FocusDismiss=0 is really a bad idea. It means that once "running", it is possible to have another another window, another skin, OR EVEN the same skin that created the input field be put "in front of" the input box, effectively blocking the field from the mouse. This is going to have undesirable results.

It also means that since the field isn't dismissed without ESC being hit, you can actually close the skin while the input field is open, which is going to be fatal. You now have a Windows "control" on the screen that is entirely dependent on a parent application (that instance of the InputText plugin) that no longer exists, and that is inherently unstable. Rainmeter crashing is quite likely.

So the answer is to use InputText carefully.

Generally keep FocusDismiss=1. Also, never use it in a skin set to "Stay topmost". (and I am leery of "Topmost" with InputText) That is likely to cause the skin to "jump in front of" the open InputText box.

If FocusDismiss=1 that will cause the InputText field to lose "focus" and dismiss when you don't want it to, and if FocusDismiss=0 you can end up with the skin all locked up and at risk of crashing Rainmeter.

So this is the reason for the InputText warnings I often get with skins in "Topmost" using FocusDismiss=1?

If you are looking for a precise description of what will happen in every circumstance, I will have to disappoint. InputText is actually terrible in my view. It does what it needs to do, and if used very gently is quite useful. However, don't push your luck with it. It needs to be "in front", it needs to be FocusDismiss=1, it should not have any meters or skins that can be "unhidden", "made solid", "moved" or otherwise made to get in front of it.

Here is how I use it.

Create a meter to be the "trigger", that will have the mouse actions on it. Logically it makes sense to have this meter look like the InputText field you will create, so there is a reasonably seamless transition from the "meter" to the "input field".

After mouse click, the meter(s) are "behind" the InputText field:

Then you type your text, and either hit Enter, or click away or hit ESC to dismiss:

test.gif

IMHO this information about InputText and FocusDismiss ought to be added to the manual or something. Surely I'm not the only one who has had experienced stuff like this with them and wondered why.

Armed on this information, I realize I can run the skin as "Topmost" but still use InputText by sending [!ZPos "0"] before ExecuteBatch loads the input box and then by sending [!ZPos "1"] when the box closes.

So far in my hasty tests there are two issues with this technique:
1. If there are windows or the taskbar behind the skin they may quickly flicker in front of it when [!ZPos "1"] is sent.
2. If another overlapping skin is in "Topmost" it will cover the skin wherever it overlaps until [!ZPos "1"] is sent.

While this is not optimal or what I had really wanted, it is a definite improvement over the original set of problems.

It looks like it might be worthwhile for me to see if there are any other better ways to get user input for my situation, like with AutoIt... (I'm guessing it would be a pain in the butt though to make a non-immersion breaking solution...)

Some additional cautions I have experienced regarding InputText measures in skins that also have bangs to refresh the config.

I experienced a similar phantom crashing issue on an InputText skin that also used mouse scroll bangs that used !WriteKeyValue and !Refresh bangs in the [Rainmeter] section; nothing to do with the Z-Position settings.

While the InputText box was active, if the Mouse Scroll bangs fired, Rainmeter would crash (stop responding to any actions) and have to be killed and restarted.

If I remember correctly the error log had an identical error message as exper1mental posted.

This is a multi-search-engine skin, scrolling the mouse changed the search engine, so I did not want to eliminate that feature.

My option is to warn in a Tooltip NOT to change engines while the text box is active.

I don't think there is a solution due to the external nature of the InputText operation as JSMorley explained. I guess caution and simplicity are the best solutions when using this plugin.

You are right eclectic-tech, a mouse scroll combined with a !Refresh is a sure way to crash things with InputText if it is "open" when you scroll. MouseOver and MouseScroll don't impact "focus", so those are dangerous if you do something that "orphans" the InputText field while it is running.

Good to know

Couldn't you prevent those crashes though by moving the bangs to an invisible image (or series of invisible images depending on the skin shape) and then by hiding the image(s) until InputText closes?

[eclectic-tech]

Couldn't you "solve" that problem (or rather, prevent the crashes) by moving the bangs to an invisible image (or series of invisible images depending on the skin shape) and then by hiding the image when activating InputText until it closes?

Well the only images in the skin defined the current search engine, hiding them was not something I wanted.
Moving them out of the [Rainmeter] section to a separate meter did not help.

I may try to use !SetOption bangs to eliminate the mousescroll actions while the text box is active, then reset them when it closes...

When I eventually get around to it!