I have a C++/CLI project which has a child form with some control components. I would like to copy all the control components with their codes on a new Tab control on the main form. How can I do that?
You can select all of the controls in the designer (hold down the Shift key to make multiple selections), and then cut and paste them to their new location: Ctrl+X, Ctrl+V
Alternatively, you can open up the *.Designer file that is generated automatically by the Windows Forms designer and copy the relevant lines of code out of that file into your other code file. Look for the code that creates and sets properties on the controls you're interested in. For every property of the control that you have set to its non-default value in the designer, there will be a line for it in this file.
If, instead of moving (cutting) the controls from one place to another, you want to copy the controls so that they appear in multiple places, I strongly suggest creating a UserControl that contains all of the child controls and encapsulates the relevant code. Then, you can just drop an instance of this custom UserControl out of your toolbox into whatever form you want, or even dynamically create instances at runtime. This is consistent with the general programming/design principle that you should seek to keep code duplication to a minimum while encapsulating as much as possible.
Related
So I'm writing a script to modify quickly a VB6 application's interface with COM controls. (Created in C# .net). Most of it works fine, but some panels are giving me a lot of trouble.
Basically, I open the .frm file and read it, and when I find some controls I modify their values or insert new things. When I find a panel, I create a different panel around it so it looks better. I'll put, say Top = 2340 in the file for my new element. If I open the .frm in notepad, I can clearly see that the value of Top is at 2340. Once I open VB6, the panel's top value is at Top = 8190. It also modifies the Left value, but nothing else. If I save and exit vb6, then reopen the .frm in notepad, the Top value will be saved at 8190.
Why does VB6 uses different values than the ones in the .frm file? Is it trying to avoid elements stacking on top of each other ? What is happening between reading the file and opening it, that forces a different value of the Top property?
Just a theory, but I believe the issue is that the ScaleMode property isn't setup right. By default, unless the container window has the property, it'll be set to Twips. So what may be valid under certain containers won't be valid in other containers.
The MDIForm container, for example, forces Twips, and may even re-position objects based on alignment.
If this is the form itself, which I don't think it is but worth mentioning, make sure the StartUpPosition is properly set to 0 (Manual).
In my WinAPI program I use PropertySheet for a settings dialog box. I use property sheet with pages (tabs), i.e. I use PSH_PROPSHEETPAGE flag. But the software now have too many parameters for such a type of property sheet. So I want to use PropertySheet with treeview: the treeview on the left and the page with paramerets for the currently selected item in the treeview - on the right.
How can I do this? Can my current property sheet be modified for this and how?
(using only WinAPI, no MFC)
Standard property sheet is no longer good enough for you, so you basically have two choices here. You can either design a window (modal or modeless, dialog based or not) to host all your controls in a single view, with tree view, possibly tab control as well, and showing/hiding elements to follow tree view selection. And you will move all your controls into this window.
Or instead, you can create a similar window which hosts property pages. On tree selection change you will switch property pages as if they are selected by tabs in standard property sheet. The point is that you can use your existing pages intact making this new settings windows imitating behavior of standard property sheet. This is perhaps a more complicated thing to do, but should be flexible enough to do once and accept various pages, and you don't also need to touch your existing pages code leaving it good for both standard and this custom sheet with a tree.
Both ways assume you need to do quite some work since you are giving up using a standard piece of code - the property sheet window.
Is it somehow possible to insert an EditorArea into a View in Eclipse RCP?
I would like to define a restricted area, inside of which the Editors may be moved.
Not easily - in general, there is 'one' EditorArea for an Eclipse application.
You could use a custom presentation layer to put that EditorArea over one of your views, but that would be it.
A potential (high-level) solution would likely involve passing an EditorPart instance to a custom view, which will then call createPartControl to render the editor contents inside the view, and manage any necessary initialization of the editor.
Since this editor would be a child control of the view, you might also need to do special hookups for selection/editorsite/actionbars/shortcut keys, etc, so that they continue to work when that editor is being run from within the view.
We have an in house button control, and quite frankly it sucks. I'd like to replace it but I don't want to go onto every form in our project and delete/add a new control. It seems to me that if I design a new button that has all the same properties as the old one then I ought to be able to give it the same name as the old one and just replace all the reference lines in the vbp files to point to the new control.
Has anyone tried this (better yet have you heard of a tool that will do it for you) and if so what 'gotchas' should I be on the look out for?
Thanks!
The *.vbp files are one place you'll need to change. There are also references to the used control libraries in the files containing GUIs -- that's form (*.frm), control (*.ctl), and property page (*.pag) files. These files are in a plain text format and you can see the references at the top. They look like this:
Object = "{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0"; "mscomctl.ocx"
Those refs will need to be added or updated in all relevant files if the new control is a compiled OCX. If it's in the same project I don't think it needs any reference there, and if it's in a different project in the same project group I'm not sure. Save a test form with the new control to see.
Note that you don't have to keep the same control class name. Inside the *.frm/ctl/pag files, instances of individual controls on them are represented by a simple format like this:
Begin VB.CommandButton Command2
Caption = "Cancel"
Height = 375
Left = 2460
TabIndex = 1
Top = 2400
Width = 1455
End
The syntax of the first line there is "Begin LibraryOrProjectName.ClassName NameOfThisInstance". So, provided the offending control's name is distinctive it should be easy to search & replace references to it both in the BASIC source and in the GUI layouts. You might want a plain text editor that can perform search and replace across multiple files (Notepad++ is one).
Some control properties are stored like this:
Picture = "frmMain.frx":292F
These correspond to the *.frx, *.ctx, and *.pgx files, which contain binary data for the values of certain control properties. I don't think these files should need altering or cause any problems. They don't appear to contain control names.
Use a full compile (Ctrl+F5) to be sure no problems linger in parts of the source afterward.
Never tried it. Good luck.
There is only one tip to be added to the accepted answer.
If you need to replace any generic VB control with 3rd party or custom ActiveX control you must replace the:
BeginProperty Font
with
BeginProperty Font {0BE35203-8F91-11CE-9DE3-00AA004BB851}
Omiting to do so results with run-time error 713 when trying to edit/open the form.
If there is no BeginProperty statement in the block then control uses default font and this replacement is not needed.
An additional scenario to look for is if the classes in the OCX are referenced directly in code.
In other words, if the control class was ABCButton then you need to look for ABCButton in all .BAS and .CLS files as well, and make appropriate changes.
Is it possible to create a dialog ressource with a resource editor and then put this dialog (possibly multiple times) into another dialog?
Here's some background. I need to create a C++ program (Windows). The user needs to input a set of similar data on a dialog. Say, for simplicity's sake, an element of this data-set consist of an edit control and a scrollbar. Since this combination (edit + scrollbar) needs to be put onto the dialog for each element for the data-set, I thought I could create a simple dialog with just one edit control and one scrollbar, and then put this dialog mutliple times onto its "parent" dialog.
So, is this possible at all. Any pointers will be greatly appreciated.
Yes, you can do this.
In the dialog editor, set the "Control Parent" flag on the parent dialog. (This will ensure the tab key works to cycle through items in the child dialogs as if they were part of the parent dialog.)
Make sure the child dialog(s) have the "Child" flag set in the dialog editor. Visually, they'll look like dialogs without any border at all in the editor.
At runtime, create the child dialogs as children of the parent dialog using CreateDialog (or CreateDialogParam, etc.). When calling CreateDialog you specify the dialogproc for each window.
I often make the child dialog procs do little more than forward messages to the main window's dialog proc (calling it directly; not via SendMessage), but you have to be careful, obviously. You have to be especially careful if you are creating multiple copies of the same dialog in a single parent, since obviously the control IDs within that dialog will all be the same and you need to differentiate them (perhaps by the parent's hWnd).
You don't have to forward messages to the parent, though. I just do usually do that so that most of the dialog's logic is in one place instead of spread out.
EDIT: Corrected statements about creating the child dialogs, window classes etc. I was mixing up dialogs and normal windows, making things more complex than they are in this case. Sorry about that!