I have a custom dialog which has an extension wid (CustomDialog.wid) and has a helper library to go with it written in C++. The helper library searches for SQL Servers in the network and fills the combobox in the custom dialog. It also saves the server name or IP address so that it may be used by custom actions later.
Can I use this custom dialog directly in WiX or do I need to create a WiX supported custom dialog?
You can convert them into WiX format by building a Visual Studio Setup and Deployment project and then using WiX's dark.exe to create a .wxs file. The output may or may not be completely useful but it's worth a try. You'd probably want to make the dialog size and layout are the same as any "built-in" WiX dialogs you might use in your new project.
Related
I am upgrading a windows forms app. The app uses an active x control (ocx) file. We have gotten the ocx to compile and can register it. The main class in the C++ active x control project is a COleControlModule. When I go to add the control to the windows forms app like this
Me.Controls.Add(Me.ActiveXClass)
I get
Unable to cast COM object of type 'System.__ComObject' to class type
'System.Windows.Forms.Control'.
I know the active x class is a com object and I know that this COleControlModule class must not be compatible with a windows forms control. Is there anything I can do to make this work?
Any help is greatly appreciated.
This isn't working because a Runtime Callable Wrapper (RCW) is not a Windows Forms control. Only Windows Forms controls will work; to use an ActiveX control with the form, you must generate a Windows Forms wrapper for the ActiveX control. This is done with Aximp.exe, typically via adding the control to the Toolbox, as Hans suggested and then dragging an instance of the control to the form.
The steps are:
Select 'Choose Items, either from the Tools menu or by right-clicking the Tools tab
Select the COM Components tab
Select the ActiveX control either directly from the list or through the Browse button
From the Tools dialog, select the newly-added component with the mouse and drag it to the form.
A reference to the ActiveX control will be added to the project, as in this sample with the Adobe PDF reader:
<ItemGroup>
<COMReference Include="AcroPDFLib">
<Guid>{05BFD3F1-6319-4F30-B752-C7A22889BCC4}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>0</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
<COMReference Include="AxAcroPDFLib">
<Guid>{05BFD3F1-6319-4F30-B752-C7A22889BCC4}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>0</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>aximp</WrapperTool>
<Isolated>False</Isolated>
</COMReference>
</ItemGroup>
Note there are two entries, one to generate a Runtime Callable Wrapper (via tlbimp), and another to generate the AxImp wrapper (via aximp). These will be viewable in Solution View, under the project's references.
I have two projects, an old project using the Win32 API that has an old toolbar using Win32 graphics and another one using MFC code with better graphics (I am creating a ribbon toolbar similar to the one that Microsoft Office uses). The MFC classes I use inherit from CDialogEx and CWinApp.
What I am trying to do is to place the ribbon toolbar in my Win32 window and replace the old one. I am already referencing the MFC project using it as a static library and can call the classes from my Win32 project but I can't get to show the new toolbar yet.
What do I need to do in order to achieve this?
It might be much easier to create the freamework with the MFC and move the old code into the new framework.
It is possible to create a MFC project without Doc/View architecture.
The MFC Ribbons will and can only live inside a CMFCFrameWnd that is part of a CWinAppEx... extracting just the ribbon code into a plain Win32 application should fail.
But there is also a Win32 Ribbon Framework. It might be much easier to implement this into your old Win32 project.
How to implement this is described here.
In Codeproject you find a sample how to use it.
I'm currently using 3d's Max 2016 SDK via MV Studio 2012. I've created usual project with Plugin Wizard, it creates panel with text and button (and does many actions inside the code, but that is not the theme).
So, now I want to add some button to activate Windows File Dialog to choose path (folder) and name of .bin-file that will be created afterwards.
I tried to find something in the toolbox at the resource editor but have not succeed.
What should I do?
As you said, you can use directly winapi to create your dialog, but the aesthetic result of the window should differ a bit from dialog already used in 3dsMax. Autodesk has made a lot of UI controls by themselves (or patched winapi ones) and provide their access in the SDK to have something homogeneous between the application and plugins.
What you are looking for here, is the function named DoMaxSaveAsDialog and should be available in Interface8.
Interface8 Class Reference
The problem is solved de-facto. Just used pushbutton and GetSaveFileName function from windows.h header.
For details, read here:
how to save file with GetSaveFileName in win32?
I have a (maybe ridiculous) question about MFC - can an SDI application support multiple document types? (Along with showing the "choose-document" dialogue when creating a new document, but that's not absolutely necessary and I could handle it myself.) What I want to do is my app to behave like modern office programs, that is each new document (of some type) residing in its own instance of the application, instead of sharing a common space with other open documents (the concept of MDI).
If SDI cannot give such functionality (which my recent experimentation suggests), could someone advice me how to handle the "open" command under MDI to open the file in a new instance of the application? (The same then applies to the "new" command.)
MFC calls this application type "Multiple top-level documents", and you can select it in MFC App Wizard:
you just have to add the document tamplates using CWinApp::AddDocTemplate
The msdn link provides only the example with CMultiDocTemplate, so I've included here the example with CSingleDocTemplate that is generated when you create a new project with visual studio.
// Register the application's document templates. Document templates
// serve as the connection between documents, frame windows and views
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CSDITestDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CSDITestView));
if (!pDocTemplate)
return FALSE;
AddDocTemplate(pDocTemplate);
I have an older MFC project build in VS 2003 that I want to port to VS 2010. The project uses an ActiveX control for grids, namely, VSFlexGrid7 from Component One. The problem is, that this version of the ActiveX control does not work in Windows 7 (which is what I have). There is a newer version of the grid, namely, VSFlexGrid8 which should be compatible with Windows 7.
The solution would be to replace all the older controls with the newer ones.
My question is, what would be the steps in replacing the controls, without touching other parts of the project. What is the simplest method to accomplish this? Do I have to modify classes, resource IDs, etc.?
[Solution: Replace CLSIDs in the .RC file]
The ActiveX control is bound to the resource file via the guid that represents the control. If you were to look inside the .rc file you will see the control with the associated guid. In your case, it's probably best to completely remove the control from the dialog (using the resource editor) assuming that you can drag the newer version onto the same dialog. Once you've done that, you'll need to generate a new class wrapper for the control. The class wizard should be able to handle that for you. Once you've got a new class wrapper that represents the control, you'll need to replace the prior wrapper class in your source code.
Usually the control is created somewhere in your dialog code with CreateInstance.
If the interface is compatible (I assume it is) , you just have to change the name or GUID that is used in the CreateInstance Code.