I have a VB6 application with a lot of controls (sometimes even reaching the maximum set by VB6 for a form, we then create custom control to bypass this limit).
On some PC, some buttons/combobox/checkbox disappear. They appear when you click where they actually are and still fire the events, but until the click you're just not able to see it. It's just 1 or 2 controls of the form, everything else is behaving like it should.
It appears on some PC, not all, and the "hidden" controls are not the same from PC to PC (and the majority of the PC the soft runs on have no problem at all).
The Visible property is of course set to true. I can't even reproduce the problem at will...
Do you have any idea of what can cause that? Thank you.
Related
I have a small utility app written in Visual Basic 6 that has been happily running on XP clients for many years until recently a client who is using Windows 7 has notified and shown me that the behaviour is different.
When my VB app displays the dialog, it remains hidden until the user clicks on it in the taskbar.
I changed the code so rather than using a ".show vbModal" command, I changed to displaying the form with non-modally, and then added various API calls like BringWindowToFront and SetWindowPos to make it top most AND calling .focus on the form, despite these extra instructions the best result I can achieve is to make the form flash prompting the user to click on it.
No matter what I've tried I cannot make the window display topmost, and with focus, without user intervention.
Note. this is an ActiveX exe project and is being called by a Win16 app through COM.
Has anyone else encountered this behaviour and know of a solution?
Any suggestions/advice appreciated, thanks.
Applications can't (without lying to Windows) steal focus. The calling app should really call AllowSetForegroundWindow() (if it's available on win16) to allow the COM process to steal the focus, or call SetForegroundWindow() itself.
See the help for SetForegroundWindow() for the conditions on setting focus.
I ran into a strange issue concerning the usage of the WebBrowser control in windows phone applications. The thing is when you use WebBrowser control it "steals" the focus and prevents setting it to any other control until a user input occurs. The WebBrowser itself doesn't even have to be on the same page as the textbox.
Consider a scenario:
Create an empty application.
Put a WebBrowser and a TextBox on your main page (rootvisual).
Now in the page loaded event (or anywhere else) try to set the focus on the textbox tbx.Focus();
The textbox will theoretically have the focus, the SIP (software keyboard) will slide up ... but the textbox will lack a cursor and you won't be able to type anything.
The same thing happens if you put the textbox on a different page and navigate to it with the appbar without touching anything else after the app starts.
The FocusManager.GetFocusedElement() shows that our textbox indeed has the focus.
How to fix this issue? Very annoying :)
Btw. the problem exists on:
- devices running version 7.0.7004.0 (before NoDo, initial release?)
- devices running NoDo
The problem does NOT exist on:
- devices running Mango
- emulator (7.1 designed for Mango)
Thx for any help.
This is a known problem, and as far as I know there is no way around it, although I've tried (setting focus in a timer, etc).
I want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.
I am debugging an application which, in its message loop, calls IsDialogMessage(). Occasionally, IsDialogMessage() never returns (where never is an interval greater than 1 hour). Based on the symbols for user32.dll available from Microsoft's symbol server, it appears to be stuck in GetNextDlgGroupItem() (or an internal variant of the same), iterating over some set of windows.
The application is multithreaded and frequently receives notification of external events, which arrive as DCOM calls. I suspect that such a call is handled incorrectly in a way that corrupts some window state. If I can learn what sort of state corruption might cause an infinite loop in IsDialogMessage(), I think I will be more easily able to identify the source of the corruption.
I know this is old, but answering for posterity since no one here mentioned it.
More than likely what is going on is trouble with the windows manager determining where to forward a message. If you have a hierarchy of windows, as you probably do, then you need to ensure that non-top-level windows that contain controls themselves must have the WS_EX_CONTROLPARENT style set. If it is a dialog, you use the DS_CONTROL style. The presence of these flags modify the behavior of IsDialogMessage; they identify a window as having its own controls which can receive focus and handle tab order, etc, rather than just being a control itself.
For example, if you have a main frame window, which has a child window with WS_EX_CONTROLPARENT, which has a child window without WS_EX_CONTROLPARENT, which has a child window that has focus, and you hit TAB, you will likely encounter an infinite loop at the same place you mention.
Setting the second child's extended style to include WS_EX_CONTROLPARENT will resolve the issue.
Are you maybe disabling controls (using ::EnableWindow()) without checking first whether that control has the focus? If yes, then the focus gets lost and GetNextDlgGroupItem() gets confused.
Another reason this can happen is if you reparent a modeless dialog. At least this can happen with wxWidgets...
I've made some investigation, trying to answer this question. But only in situation, when parent window is in native MFC project and child is a managed C# Windows Forms. If you have such situation, then you may try 3 resolutions:
Run MFC dialog message loop on Windows Forms side. Here is more info: Integrate Windows Forms Into Your MFC Applications Through C++ Interop
Create 2 threads: one for Windows Forms dialog and one for native dialog. Here you can create dialog in Windows Forms, then with SetParent() set it's parent to native dialog. But be ware: if you add TabControl to Windows Forms, than hang with "IsDialogMessage() never return" will occur.
Make a wrapper for Windows Forms dialog to use in native project. For ex., wrapper may be WPF, see here: Windows Form as child window of an unmanaged app
I've taken information mostly from: http://msdn.microsoft.com/en-us/library/ms229600.aspx
And the temporary cure can be to change focus behavior. For example, disable them, or SetFocus() to parent or child windows only. But I strongly recommend to investigate the real reason, why IsDialogMessage() never return in your case.
We have a service that launches an application that will interact with the logged on user. The application we launch is always run as a specific user for which we have the credentials. We do what is necessary (get active session ID, logonUser, adjust token) and launch the application with CreateProcessAsUser in the winsta0\Default desktop.
Everything is working fine if the color scheme of the Vista PC is Aero - but under the basic and classic color schemes, the application is still launched but none of the windows are painted. There is a new task on the taskbar. If you minimize a window which was in the background and in full screen, then you can see the contour of our ghost app - you can move it around, it will respond to keyboard/mouse input just fine. It's just invisible, not painted.
Does anyone has any idea of what could be happening? Why with the Aero color scheme it's fine but not in the others?
Thanks for any help,
Frank
It sounds pretty weird - you may have hit on an actual bug in Vista since it seems unlikely many other people have tried what you are doing.
First of all I'd make sure the problem doesn't exhibit this behaviour when run by the logged in user directly, just to pin it down to whether it's a Aero/Classic issue or a winstation issue.
Secondly I'd attach to the process with a debugger and make sure the message loop is getting various significant messages, particularly WM_PAINT :)
But this is obscure enough that your only option may be to open a paid support issue with Microsoft.
There may also be a problem if you have user-drawn controls on your form (or your form itself is user-drawn). If you only paint the form if Application.RenderWithVisualStyles is true, you may see this behaviour. So make sure you also render stuff without these styles. More information how your form looks/behaves/etc would be appreciated.