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.
Related
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?
I want to create a control in WinAPI which works like some toolbar buttons do: you can click the button but it cannot be focused; the focus stays on the control that had it. How do I go about it?
This is not a complete answer because I've abandoned the task eventually, but what I found is that in fact, controls have to SetFocus(Self) manually and they usually do that in WM_LMOUSEDOWN handlers.
So to handle clicks like toolbar buttons do, it's enough to not do that.
Problem is, standard controls and common frameworks usually do this automatically deep in their internals. With frameworks such as MFC or VCL it might be possible to hack this off somehow, standard WM_LMOUSEDOWN handler for BUTTON control seems to do SetFocus, and it can't simply be skipped because it also does click processing.
I've removed the menu from my cocoa app, all of the interaction should happen from within a status item, that links to a menu, that links to different NSPanels. But this seems to have removed the ability to ⌘C or ⌘V within a NSTextField. Is there a way to add this back without having to have a standard menu included with my app?
Even if your app is a faceless background app, so it never shows a menu bar, you should still have a full main menu because that's what provides all of the default actions (and enables the user to redefine the key commands if they so choose). If you remove the main menu, you have to reimplement everything in it, including anything Apple adds in the future, in code.
And I'd especially warn you against trying to handle keyboard shortcuts yourself. That's damned tricky. A lot of applications get it wrong, causing us Dvorak users (among others) to curse their developers.
I assume you can just implement the actions originally connected to the menu items in a keyDown event. Check out this page for details: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html
Just have it respond to cmd-v with paste:, and cmd-C with copy:
Edit: Though I have to agree with Peter, you really should have a main menu...
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.
Even when BorderStyle is set to 0, it is possible to force a window to show up on the taskbar either by turning on the ShowInTaskbar property or by using the windows api directly: SetWindowLong Me.hwnd, GWL_EXSTYLE, GetWindowLong(Me.hwnd, Win.GWL_EXSTYLE) Or Win.WS_EX_APPWINDOW. However, such taskbar entries lack a right-click menu in their taskbar entry. Right-clicking them does nothing instead of bringing up a context menu. Is there a way, to attach a standard or custom handler to it?
Without a hack, I think you're going to be stuck here, I'm sorry to say. When you set the VB6 borderless properties, you inherently disable the control menu. The control menu (typically activated by right-clicking the title bar of a window or left-clicking the icon in the upper left) is what's displayed when you right-click a window in the task bar.
Now, if you're in the mood to hack, you might be able to "simulate" the behavior in such a way that the user doesn't know the difference. I got the idea from this message thread on usenet.
Basically, it sounds like you may be able to hack it by using two forms. One form is minimized right away, and becomes your "stub" in the task bar. The other form is the one you're currently designing (which we'll call the "main" form). The stub form is what actually loads and displays your main form.
The stub form isn't borderless, and must not deactivate the control menu. It is positioned off screen and at the smallest possible size. You'll respond to its form-level events, and then use those to communicate the appropriate behaviors to the borderless form.
That's the general gist of the hack. If I wasn't at work right now, I'd whip up a simple VB6 project and see if I could get it to work for you.