I'm developing an application with a lot of small, custom dialogs.
These dialogs are e.g. giving choices, displaying graphs or offer additional interfaces. Mostly they require very little markup-code and have few child elements.
Currently I'm using embarcadero'c XE2 RAD Studio's C++ Builder, which works with VCL and generates for every form a .dfm file, a .h file and a .cpp file.
Now I would like to keep an overview over the files produced and merge e.g. the .dfm files of multiple small dialogs. (maybe even the .cpp and .h, too).
However, I also want to use C++-Builder's VCL designer.
Is there a way to merge .dfm files and still have the IDE's designer working as usual?
Or should I just dynamically generate those dialogs during runtime?
Now I would like to keep an overview over the files produced and merge e.g. the .dfm files of multiple small dialogs. (maybe even the .cpp and .h, too). However, I also want to use C++-Builder's VCL designer.
Is there a way to merge .dfm files and still have the IDE's designer working as usual?
It is possible (but not recommended) to move design-time generated event handler implementations from one .cpp file to another .cpp file (don't move their declarations in .h files, though). So it is conceivable to have 1 .cpp file with all your event handler implementations, and the app will work fine. I do the opposite in one of my projects - I have a TForm with a LOT of event handlers on it, so I move them into separate .cpp files grouped by functionality (yes, I should use TFrame to manage that, but I am not at liberty to change that at this stage of development).
There is a side effect, though - if you try to double-click on an assigned event in the Object Inspector, it won't be able to find the handler's implementation code if you move it.
However, regarding DFMs, every TForm, TFrame, and TDataModule class that is created at design-time must have its own individual DFM. The IDE and the DFM streaming system both expect that. DFM resources in the final executable are identified by class name, and the DFM streaming system reads an entire DFM resource from start to end when loading a DFM into a single root object instance. Besides, the DFM data format does not support multiple DFMs in a single resource stream.
So no, you cannot merge multiple DFMs together.
Or should I just dynamically generate those dialogs during runtime?
Yes. Or just live with letting the dialogs use individiual DFM resources. If your dialogs really are as small on content as you say, the overhead to your executable should be minimal.
You can use "legacy" TNotebook component ("Win3.1" page in RAD2007) to simulate many small dialogs in one file; it works like page control without tab buttons. Create required number of pages in the component and activate needed page in constructor of the form.
Related
I am trying to recreate a Visual C++ Solution that had about 30 projects so that the general organization will be cleaner.
The original "solution" was in fact a Visual C++ 6 workspace from the turn of the century, migrated into VS 2017.
Some of the projects will be close to being clones of the old ones.
When I try to create a project, I am asked what Application Type it must be:
Single Document/Multiple document/Dialog based or Multiple top level documents.
I thought I could guess this by looking at the property pages of the existing documents, but I can't seem to find it. Or am I likely to be going in the wrong direction?
As far as I'm concerned, we couldn't guess this by looking at the property pages of the existing documents. I suggest that you could check MainFrm.cpp in the project source file to distinguish the project from a single document / multiple documents / dialog based or multiple top-level documents.
A multiple documents:the document's frame window can hold multiple child windows.
IMPLEMENT_DYNAMIC(CMainFrame, CMDIFrameWndEx)
A single document:the document's frame window can hold only one document.
IMPLEMENT_DYNCREATE(CMainFrame, CFrameWndEx)
dialog based: There is no MainFrm.cpp in the source file.
multiple top-level documents:Creates a multiple top-level architecture for your application, where a view class is based on CView.
IMPLEMENT_DYNCREATE(CMainFrame, CFrameWndEx)
clicks New Frame on the File menu:
For more details, I suggest you could refer to the Application Type, MFC Application Wizard
I am researching a way of implementing a simple file system UI. The requirement is that I have an in-memory tree (custom data structure), similar to a file system. But this is not the real file system of the computer. So, I want to represent this internal implementation to the user to react with that like adding new files, deleting files, editing files, adding folders, i.e. the basic operations.
I have no idea how to achieve this using Qt UIs. Is that a good idea to represent these files/folders using QLabel and setting pixmap for them?
If I implement it like this, it is lot of work, like, once the folder is clicked, the frame should be cleared and the new set of labels should be loaded in the same frame.
What will be the easiest way?
I was storing my classes in static libraries.For example modify the original header file like adding line pragma comment(lib,"MyClass") then copy files to the visual studio's include and lib folder.Whatever everything was fine until i wanted to add Menu to my class.Lib files does not have resources so i am going to use dynamic link library for this class.Is this logical that storing classes in dlls? also i dont know how to use dlls like that...
is there some examples for this? Also there is classes like CFileDialog that have resources(dialog) this kind of classes use static libraries or dynamic ?
To me, this sounds like "the wrong place to split things". In other words, if your library needs a resource that is part of the application, then it's probably not meant to be a library in the first place - it is either a proper standalone DLL that contains its own resource, because it has a complete and standalone functionality, or it's actually part of the main executable, and uses the main executable's resource.
The point of making something into a library is that it allows the separation of the library contents from the main application.
Another option is of course that you pass in the relevant resource information from the main application to your class in the library [this works for a a DLL too, of course].
My point here is that a menu is something that belongs to the main application - it knows what it has under File, Edit, View, etc. If you are writing a word processor, you may have things like "Spell checking" in there, but you don't want "Spell checking" in the Photo Editor software, but you probably want some way to get colour profile information to match the monitor's colour balance with the official colours. So your "class" to handle menus probably shouldn't "know" what the menus are, but just how to deal with menus in general - what menus you have comes from the actual main application.
I know this isn't really a direct answer to your questions...
Vista introduced an interface: IFileDialog::SetFilter, which allows me to setup a filter that will be called for every potential filename to see if it should be shown to the user.
Microsoft removed that in Windows 7, and didn't support it in XP.
I am trying to customize the our Open file dialog so that I can control which files are displayed to the end user. These files are marked internally with a product-code - there isn't anything in the filename itself to filter on (hence file extension filters are not useful here -= I need to actually interrogate each one to see if it is within the extra filter parameters that our users specified).
I would guess that Microsoft removed the SetFilter interface because too often it was too slow. I can imagine all sorts of similar ideas to this one which don't scale well for networks and cloud storage and what have you.
However, I need to know if there is an alternative interface that accomplishes the same goal, or if I really am restricted to only looking at the file extension for filtering purposes in my File dialogs?
Follow-up:
After looking further into CDN_INCLUDEITEM, which requires the pre-vista version of OPENFILENAME, I have found that this is the most useless API imaginable. It only filters NON-filesystem objects. In other words, you can't use it to filter files. Or folders. The very things one would filter 99.99% of the time for a file open or save dialog. Unbelievable!
There is a very old article by Paul DiLascia which offers the technique of removing each offending filename from the list view control each time the list view is updated.
However, I know from bitter experience that the list view can update over time. If you're looking at a large folder (many items) or the connection is a bit slow (heavily loaded server and/or large number of files), then the files are added to the dialog piecemeal. So one would have to filter out offending filenames repeatedly.
In fact, our current customized file open dialog uses a timer to look at the view's list of filenames periodically to see if any files of a given pattern exist, in order to enable another control. Otherwise it's possible to check for the existence of these files, find none, but a moment later the view updates to have more filenames, and no events are sent to your dialog to indicate that the view has been changed. In fact, my experience with having to write and maintain code for the common controls file dialogs over the years has been that Microsoft is not very cluefull when it comes to how to write such a thing. Events are incomplete, sent at not-useful times, repeated when not necessary, and whole classes of useful notifications don't exist.
Sadly, I think I might have to give up oh this idea. Unless someone has a thought as to how I might be able to keep up with the view spontaneously changing while the user is trying to interact with it (i.e. it would be awkward to go deleting out entries from the list view and changing the user's visual position, or highlighted files, or scroll position, etc.)
You need to initialise the callbacks for your CFileDialog. Then you need to process CDN_INCLUDEITEM notification code to include or exclude items.
You can also check this great article. The author uses some other approaches in addition to callbacks
As you have already discovered, starting in Windows 7 it is no longer possible to filter out files from being displayed based on content, only file extension. You can, however, validate that the user's selected file(s) are acceptable to you before allowing the dialog to close, and if they are not then display a message box to the user and keep the dialog open. That is the best you will be able to do unless you create your own custom dialog.
Modern screens have large resolutions, fitting two or three columns of 80-column code easily. C++ basically requires that you separate your code into .hpp and .cpp files.
So, to utilize this space, why not automatically open the .cpp file in a second column when you open a .hpp file (and vice versa)? This obviously wouldn't work for extreme cases, although for a lot of projects there is a direct correspondence between the filenames that would be easy to determine. To me, this seems like a very reasonable use of this space, and it's hard to imagine it hasn't been done.
Is there an IDE that does this? A plugin? Or, why do you think it can't be done?
If you're in Visual Studio, a plugin (Visual Assist X), which is already very nice to have for C++ projects has a similar feature. It's not completely automatic, but all you have to do is press Alt+o and it will open the other file in the set. That is, if you're .hpp pressing the key will open the .cpp, and vice versa.
Their website demonstrates how this works in a video. It also works for things like XAML/Code Behind files, Windows Forms/Code files, etc. (Basically anywhere files operate in pairs, that key combo switches to the other file in the pair)