I am unable to edit the text in an IP Address control. I can select it and delete it with the mouse but typing into it causes the test to go to the window it was started in.
Disabling the control does not change it's color.
Is anyone working on this control?
Robert Reif wrote:
I am unable to edit the text in an IP Address control. I can select it and delete it with the mouse but typing into it causes the test to go to the window it was started in.
Hmmm. Strange. The IP address control just uses Edit windows to handle this behaviour. It looks like maybe something funky is going on with the focus handling in the Edit control. And, yes, funky is a technical term.
Disabling the control does not change it's color.
We probably need to handle WM_ENABLE (an audit needs to be done for all controls actually) and override the WM_ERASEBKGND message handler to make the control greyed.
Is anyone working on this control?
I'll take a look at it tomorrow. It doesn't look like the problems are too serious and I should be able to copy 'n' paste code from the other controls. It's kinda handy when you have other complete controls to work from.
Rob
On Sat, 05 Mar 2005 14:27:47 -0500, Robert Reif wrote:
I am unable to edit the text in an IP Address control. I can select it and delete it with the mouse but typing into it causes the test to go to the window it was started in.
Sounds like the top level container window was created unmanaged. Do you mean the text you type goes to the terminal window you started Wine from?
I tried your test program from the bug filed in bugzilla, and it works for me (ie , I can type into it OK).
I get the following error from it though when it gains focus:
err:ipaddress:IPADDRESS_GetPartIndex We subclassed the wrong window! (hwnd=0x2002a)
thanks -mike
Mike Hearn wrote:
I tried your test program from the bug filed in bugzilla, and it works for me (ie , I can type into it OK).
I get the following error from it though when it gains focus:
err:ipaddress:IPADDRESS_GetPartIndex We subclassed the wrong window! (hwnd=0x2002a)
thanks -mike
Try it with: "Managed" = "N" in your config file.
On Sun, 2005-03-06 at 10:09 -0500, Robert Reif wrote:
Try it with: "Managed" = "N" in your config file.
No, there's no point, keyboard input going to the terminal for unmanaged windows is the expected behaviour. If you want to use unmanaged windows, use Desktop mode.
Mike Hearn wrote:
On Sun, 2005-03-06 at 10:09 -0500, Robert Reif wrote:
Try it with: "Managed" = "N" in your config file.
No, there's no point, keyboard input going to the terminal for unmanaged windows is the expected behaviour. If you want to use unmanaged windows, use Desktop mode.
The real app that has this problem is dialog based and uses menus. The only way to get those menus to work is to set Managed to N. So I have to run in Desktop mode for it to work properly? That stinks. Any plans on fixing this someday?
On Sun, 06 Mar 2005 10:43:50 -0500, Robert Reif wrote:
The real app that has this problem is dialog based and uses menus. The only way to get those menus to work is to set Managed to N. So I have to run in Desktop mode for it to work properly? That stinks. Any plans on fixing this someday?
Hmm, why do menus in dialogs not work in managed mode? I think that's the real bug here.
And yeah, nailing the whole managed/unmanaged thing is something I'd dearly love to see. The "Managed" config file option is pretty meaningless, unmanaged windows basically never work right for everything. Now the WM rewrite is complete hopefully we can improve the way we deal with this stuff a lot.
-
Mike Hearn -
Rob Shearman -
Robert Reif