How do I prevent users from dragging windows around? - windows

I've inherited a project that presents users a set of tabs, each of which contains a view that displays multiple components. In some of these tabs, we want to prevent users from moving the components displayed in the tab.
We have an object that inherits from CMFCTabCtrl to manage our tabs, which contains a collection of CWnd objects that represent each of our tabs. We also have an object that manages the views associated with each of these tabs, and activates those views when the relevant tab is activated.
The components all share a base object which inherits from CWnd, which defines the various handlers for the messages defined in the inherited message map.
What would be the correct/best way to prevent a user from dragging those components around?
Thanks!

One solution is to remove the titlebar style from the component CWnds. Without a titlebar the user cannot drag the window.
Another approach is to handle the WM_NCHITEST message in the component CWnds. If you return appropriate values the user's mouse will not be recognized as on the titlebar when they click.

Moving of the components is not a feature of Windows that is turned on by default. The code for moving the components exists in your project. That code has to be disabled in those cases where you want it disabled.
I assume that by components you mean controls and some such, and not child windows, like in MDI type of applications.

Try and set CMFCTabCtrl::m_bActivateOnBtnUp to TRUE.
This might deactive the Drag&Droip stuff.

Related

MFC:CDHtmlDialog Purpose/Usages to open other views?

I was thinking of writing a new app where a users selects an option of what procedure they want to perform and the view changes to that until done then goes back to the main menu. I came across CDHtmlDialog and looked like a nice easy way to add a nice looking menu using html. But I wonder if that is the purpose of that class? Can I set it up so when a button or graphic link is clicked it changes out the view to another one (I would need to use traditional things like CTreeView with CListView with a splitter) or is it more for staying within the HTML world?
Thanks.
From the MSDN MSDN documentation
CDHtmlDialog Class is used to create dialog boxes that use HTML rather than dialog resources to implement their user interface.
From what I can gather from your post, I think you should consider SDI application using view classes that you want. To switch views on the command you do not need a splitter window. A static splitter is used to display a number of views in a different part of the splitter simultaneously.

Is there a JPanel equivalent for MFC

Im my application I want to implement the feature of when a user click on a button show a Panel which will consist of some user controls. I know In Java I can easily use Jpanel and use setVisible() method to get this done easily. But this is an MFC application. I couldn't find any built or customized component that I can use for my purpose.
I also tried GroupBox. But it is not grouping the components logically.
What would be the best approach for this?
As user1793036 says, start by creating a dialog resource and CDialog derived class for the panel. In the dialog resource properties turn off the Title Bar style. In the code call Create for the dialog and then SetWindowPos to place it where you want it to appear.
MFC is nothing but a thin wrapper over Win32 API for windows and controls. The core Win32 API doesn't provide any feature to group controls in a group-box or panel. One way is to have a window and make that window parent of all required controls. Unfortunately, this isn't easy to do.
I suggest you, since you are learning, to drop the idea. Instead, learn what you can achieve with existing set of features provided by MFC/Win32. With MFC/Win32, you would, mostly need to derive/subclass a class/window to get something fancy (such as colored list-control).

How should toolbars, menus, and their commands be implemented in a desktop application?

At a conceptual level (not platform/framework specific), how should components like toolbars and menus (and the commands they contain) be implemented in a desktop application that uses the MVC pattern, with minimum coupling & maximum code reuse?
Generally, commands are bound to menu items, toolbar buttons etc. would expose following information to controls:
Executing method
Enabled/Disabled flag
(Optional) Visible/Hidden flag
(Optional) Icon
(Optional) Text
(Optional) Description
Event notified about command state is changed
If you prefer to use MVC pattern, not MVVM, you probably being hard to determine where command logic would be placed. You may expose these information via model, or you may place corresponding code in controller.
If you use component-based UI, like .NET WPF/WindowsForms/Silverlight etc., you probably may create interface for the command that exposes all listed properties, and create custom controls inherited from MenuItem, ToolbarButton etc. that handles information from such interface.

Changing Views Within a Prism Module?

So I have a PRISM v2 (M-V-VM) application up and running. It's 4 modules that load into a tab control. Great.
Now my question is - where to go from here? Most tutorials seem to stop at this point.
Maybe I'm overthinking this, but it almost seems like I'd need each module to be its own PRISM application, but that can't be right.
Please help a PRISM n00b figure out where to go from here.
What I'm looking to do next: Each tab (module) has its own toolbar with buttons, etc. Clicking a button should change the content (view) below the toolbar.
How to achieve this (correctly) with PRISM? Each module (tab) should have control over its content, however, clicking cetain buttons in one tab may trigger an event in another tab (hence the use of PRISM).
So what's the correct-PRISM way to change views within a module?
I think you are thinking about this a bit hard. I'll explain.
What is commonly referred to as the "Shell" should contain all of your navigation controls. For example, if I wanted a tabbed UI, my Shell would contain a tab control (usually you'd decorate that TabControl with a RegionName, like "ShellTabs").
Your Modules will contribute views to these shell elements. So let's say you have the email module, it will contribute an inbox view to your collection of tabs. It could contribute these views by registering them with the RegionManager for the app (like registering your view with the Region called "ShellTabs").
Modules don't have to contribute anything visual. I have one module in our app that takes care of logging and other background processes.
Hopefully this clears up some of the nomenclature and helps you know what the responsibility of each part is.

Can't assign control to custom winforms panel with VS2008 winforms designer

I inherited the prototypical corporate application with a person form (with address, phone, etc).
Now on that mentioned person form one label+textfield is a child of the form itself and not of the panel it visually belongs to.
How can I change a control's parent from form to an existing panel in VS 2008 designer?
Update:
Ah, it seems to be a problem with the super magic custom group box control my beloved cow orker left for my pleasure. Dragging into a normal group box works ...
Update 2:
With the help of the Document Outline I can see that the custom "GroupBoxExt" we have in the application is defective, dragging a control onto the panel (or just changing position of a control on the panel) assigns it to the form.
Update 3:
Now that I new what was wrong (thanks for the document outline tip) I went of to google and found a custom group box on CodeGuru. The author of that artilce found out you'd need to decorate your custom panel with
[Designer("System.Windows.Forms.Design.ParentControlDesigner, System.Design", typeof(IDesigner))]
to make it behave as a nice container.
If you're looking to do this in the designer, what you're looking for is the Document Outline panel (it's under the View menu under "Other Windows"). From there you can drag controls by their name in the outline and reassign the parent.
Hope this helps!
I'm not sure exactly what your asking. Can you try clarifying the scenario a bit?
But if you want to change a controls parent, all you need to do is make that control a child of the panel using the Controls property.
myPanel.Controls.Add(target)
This should update the parent of target to be myPanel.
If you're attempting to do this via the designer, all you need to do is drag the target control onto the panel and that should take care of it.

Resources