I have some old VB 6.0 code that I need to get running on Windows 10. We are not allowed to use Compatibility mode due to security and client refusal issues.
The only problem I am having is that whenever a button is clicked on the interface the menu items (across the top) become unresponsive. If you mouse over them the shading changes but clicking does not drop down the menu. Additionally, if I generate a message box pop up and click OK the menus come back to life.
I've tried setting focus to the main form in different situations, tried refreshing the parent and child forms. Also added a brand new button with no code behind it - not even an empty click event handler - and that button when clicked causes the same issue.
I should also add that the main form is an MDI form with three child forms. The buttons of course reside on the child forms.
I'm not sure how to proceed with this at this point. I certainly can't have a message box pop up after every button is clicked. Has anyone seen this before or have any ideas as to what causes it?
Related
I am making a simple game for Unity and currently there is not much to it other than an opening cut-scene prototype. This consists of simple panels all under one canvas, each panel has a button that is supposed to disable it and enable the next panel.
Thus I start with panel 1 enabled, and under it is a button simply called 'next' When next is clicked it runs OnClick(), first it disables the first panel and then enables the second. This works just fine, however some of the other panels do not have a functioning button even though it is set to do the same thing with a different set of panels.
The later panels are literally duplicates of the first only with different panels set to enabled and disabled when the button is clicked. However some of them simply do not work when we try to click on the button there and thus nothing happens.
I would much appreciate if the people here have any insight on this issue.
I have a very large accounting system. In a user preferences section, the program has begun to act abnormally on my development machine only. No customers are reporting this, nor can I duplicate it on any of my other computers. Running Windows 8.1, others are on 7.0. Not exactly sure when this started happening because it's not the kind of thing one goes into on a regular basis. The preferences screen consists of a tab control and various standard controls. At the bottom is Okay, Cancel, and Apply buttons. All three buttons seem to be acting with the same strange behaviour. Clicking with a mouse does not generate a click event yet does not hang the system - mouseup follows and you can click it again and see the mousedown and mouseup but no click. However, since the Okay is defined as Default, pressing enter DOES create the desired click event, and all the code inside that even runs fine. Cancel and Okay also unload the form, but when clicked, that doesn't happen because none of the code gets executed, yet you can still navigate the screen (move between tabs and controls) but you can't even click the "X" button to close the form at that point.
Also, if you go straight in, and press enter, everything works and the form unloads, but if you do anything before pressing enter (or escape to cancel), like change a tab and/or edit a value, then press enter, the click event again does not run and the system semi-hangs.
I tried turning-off my anti-virus thinking that might have something to do with it, but no-go. Debugging is frustrating because while I finally got it execute the click event, the stop command inside that event (after debug.print "click") would allow stepping and success if just straight in and enter, but if anything else done as before described would stop at the stop statement (keyboard enter only still no mouse clicks under any scenario) and would do a total lock-out. In other lockouts where it would let me navigate, almost always selecting a new tab would cause a fatal error and it would force-unload VB for me, otherwise I had to use the task manager.
This is driving me nuts, but I don't know how else to debug it.
The culprit was tv_w32.dll which is Team Viewer. Turning-off Team Viewer allows my program to run normally.
I'm developing an application with tab controls. After clicking on an icon in a tab, a popup window opens and the contents of the tab are moved to the popup window.
What I do is simple - change parent of each control within the tab to the popup window (using SetParent()). Everything works great except for listview controls (virtual listview).
After changing the parent, the listview no longer sends WM_NOTIFY notifications.
I've also tested it with non-virtual listview and the same happens.
I've searched all over google and came up with nothing, so any ideas would be appreciated.
UPDATE
After changing the parent, the listview keeps sending WM_NOTIFY notifications to its previous parent. Is this a bug in common controls?
A lot of the common controls cache their parents when they are created. There's nothing you can really do about this except to create them with the right parent in the first place.
One workaround is to register a dummy window class that does nothing more than host the common control in question, and forward messages back and forwards to it. Then you can reparent that window rather than the control itself.
In a Win32 API C++ project, I have a dialog with a tab control (3 tabs) and 3 dialogs that are children of the tab control. I load the main dialog with tab control using DialogBoxParam, and the child dialogs from resources with CreateDialogParam. The main dialog appears with the child dialogs. Clicking the tabs shows/hides the correct child dialog, everything working fine.
After searching around about tab orders I found the WS_EX_CONTROLPARENT style to set on the tab control to get tabbing working into the child dialog windows. This works great, except for one problem: The tab control itself never gets focus, so I can't tab to the tab control to change to a different tab with the keyboard. Keyboard focus goes through the child dialog, to the buttons on the main dialog, then directly back to the child dialog, and never stops on the tab control itself, so I have to click on the tab control to change tabs. It's driving me crazy. Any suggestions?
Update: I managed to work around the problem by forgetting about WS_EX_CONTROLPARENT completely, and making the child dialogs siblings of the tab control. Only side effect seems to be more flashing of controls during a repaint, but would still like an answer, since making the child dialogs children of the tab seems cleaner.
Its not cleaner. The recommended way to create tabbed dialogs is to make the tab pages children of the dialog. The tab control simply controls which of the pages is visible, but is not their parent.
This is especially important when you might try to get XP themeing working on the dialog.
WS_EX_CONTROLPARENT is a style intended to be set on the actual 'tab' dialogs.
I presume you have set WS_TABSTOP on the tab control itself? I imagine that WS_TABSTOP and WS_EX_CONTROLPARENT conflict when simultaneously set as they tell the dialog manager to do two entirely different and conflicting - things when the tab cycle reaches the control.
Lastly, I cannot see any reason at all that flickering should increase because the dialog pages are children of the dialog rather than the tab control.
You can't AFAIK because tabbing cycles through the child controls of a dialog by design. Best you could do is preprocess the tab keydown event and if its after the focus is on the last control in the dialog, focus the tab page and discard the event. Not cleaner than the solution you already have it seems to me.
I have a vb6 form that I've put an ocx control on. Setting NegotiateMenus on the form displays the ocx's control (which is what I want). I then add my own control to the form. When that control has focus, the menu from the ocx disappears.
How can I always keep the menu from the ocx displayed, regardless of who has focus?
Dan, I remember trying to do something similar many years ago, and could not achieve it.
What I ended up doing was adding a empty top level menu with the same caption as the menu on the OCX control, and having it always be disabled.
Then, when the OCX got focus I would hide my disabled menu item, making it look as if clicking on the OCX had enabled the menu item. It saves all the ugly jumping around as menus appear and disappear (obviously, once the OCX lost focus I would show the disabled menu again).
If you still want the menu item enabled, you would have to replicate it exactly in your form, and hide your version of it when the Ocx is active (you would also have to wire all your own events to replicate the functionality available on the OCX.
There is no easier way of doing this at I know of.
Apologies not be being more helpful.