[RESOLVED] CFormView inside a dialog?

Hello folks, I've done a lot of research on this, but I'm not even sure if this is the correct way to approach the problem I'm encountering...

I have an app that opens a dialog with controls for the user to use, but the content displayed depends on what is inside a dynamically loaded DLL.
So basically depending on the content, I want some common controls on the bottom of the dialog, such as a forward, a reverse, and a Save To disk button that is handled by the application.
Everything above that small area on the bottom I want to let the DLL handle, as the program has no idea how to handle the data.

My thinking was to have a view in the DLL das a method in the DLL can return to the program to show that view inside a CFramwWnd that takes up most of the dialog. Either that or a CSplitterWnd...

I'm not sure though if that is the correct way to approach the problem.
What do you think? I know it is doable somehow, I just don't know if this is a recommended/good way!

Thanks in advance!
-Andy

Consider a child dialog approach. Dll creates a child dialog (non-framed dialog window) and handles its messages and events while parent dialog handles its own button events.

You can use CStatic controls like text label or picture to hold the dll's contents
What content is it ?

Thank you for your input. Igor, how with a non-framed child dialog would I be able to display controls on the dialog that are contained within the DLL?
If I understand correctly, I can load a "sub" dialog inside a specified area of the "main" dialog so to speak?

I basically want the main window to handle things like "show next" and "show previous" and the DLL the actual content.
When clicking next or previous, the content might change and a child dialog from a different DLL needs to be loaded then.

I have uploaded an image of what I'm trying to do to explain it better:
http://afiminfo.dyndns.org/files/Idea.jpg

@Pocoya: I would, but the problem is I don't know what the DLL tries to display. Whether it is video, text, other data, etc...

I don't think there is a includeable CFormView instance in a dialog
You program sounds too big, you include many unknown windows in DLLs :)

Would you mind introducing us a similar application so that we can understand your problem better ?

I'm not really sure I understand what you are trying to do. It sounds like you have all these dlls with controls in them and you want to sequence through them but you don't know where to place the controls so the operator can use them.

If this is the case I would just use a Formview and create the controls dynamically on the formview screen above the buttons. When you go to next screen just remove them from the Formview.

I do this I place and remove controls from the CFormView all the time.

Quote:

---

Originally Posted by ADSOFT

I'm not really sure I understand what you are trying to do. It sounds like you have all these dlls with controls in them and you want to sequence through them but you don't know where to place the controls so the operator can use them.

If this is the case I would just use a Formview and create the controls dynamically on the formview screen above the buttons. When you go to next screen just remove them from the Formview.

I do this I place and remove controls from the CFormView all the time.

---

Hello ADSOFT, this is what my initial thinking was, make the area above the applications buttons a formview. However I'm dealing with a dialog. Have you ever tried adding a CFormView on a dialog?

Quote:

---

Igor, how with a non-framed child dialog would I be able to display controls on the dialog that are contained within the DLL?
If I understand correctly, I can load a "sub" dialog inside a specified area of the "main" dialog so to speak?

---

Yes, precisely. You design several dialog templates: the parent with few buttons and the place reserved for child dialog, and a number of child dialogs with their controls layouts as you wish. (However, you cannot design those together in resource editor.) At runtime you need to create child dialog programmatically and specify your main dialog as parent window. In addition you might need to adjust child's position and size within parent's window. This creation may be implemented in the dll as well, as it knows every detail about child dialogs while main app is allowed to know nothing, it just provides main dialog handle.

Any dialog typically has child windows that usually are conventional controls. But the same way another dialog can be put on a main dialog, and the dialogs will have usual child-parent relation. This means, that the dialog will be "stick" with its parent, and Windows will take care about moving it along with the parent dialog.

However, from the messaging point of view, the dialogs will have their own dialog procedures and therefore, their own message handling. As long as child dialog procedure can be implemented inside the dll, the main application may have no idea about the details how dll controls the dialog, but all would work together alright.

In case the "dll" dialog (the child dialog) needs to communicate with the parent (main) dialog, it may send custom messages (or even predefined commands) to its parent.

You may be sure I used this technique in commercial projects, and all worked just fine.

In fact, this "child dialog" approach is always used when tabbed dialog is implemented, when every tab is a child dialog appropriately positioned on top of the tab control. CFormView implements similar approach as well.

In case you need seamless joining of two dialogs, the child dialog technique seems the most natural for such task.

Quote:

---

Originally Posted by namezero111111

Hello ADSOFT, this is what my initial thinking was, make the area above the applications buttons a formview. However I'm dealing with a dialog. Have you ever tried adding a CFormView on a dialog?

---

Are you saying that you are committed to starting your app from a Dialog? In other words you can't rewrite the whole app? Because if you could you could just start from a Formview.

Remember, a Formview is just a glorified dialogbox with a menu, a CFrameWnd (I think thats the class) and a nice print preview.

I could be wrong but CFormview must be part of an App. I do call CFormviews Apps from Dialog boxes, but I'm basicall executing an .Exe and hiding the dialog box.

You can also put a menu on a dialog. In other words CDialog is basically a Formview.

However, I just realized, MAYBE you can add a CFrameWnd and a CFormview as members of your Dialog Class a call a Formview.

Ask, Igor, he would know. Otherwise I think Igor is on the right track you could do what he suggest on top.

Hello ADSOFT,

I may not have been entirely clear about the project in my post. It is actually an MDI app that handles multiple data types, and one dialog opens for full-screen viewing and part of that dialog area is given to a content handler DLL that manages showing the data.
That is why I was asking about embedding a child object on a dialog.

Wow if it's a MDI and you open up Dialogs then you won't be able to switch between MDI's.

I would draw the controls in the available controls area. I'm not sure about MDI's but in formviews, you can make the View larger than the screen and then you would be albe to scroll(like a WebPage). That might give you more room.

If you want to commit to not letting the user switch between views, put the objects in a modal.

If it where me I would make the view area large like a web page, the framework will automaticall place slidebars. You might also be able to use a toolbar to free up space in the client area.

Is there a finite number of dlls? And does each dll have a finite number of objects?

Now that I think about it, a splitview with a FormView might be more elgent. Actually a split view with a Tree, a FormView for each object group, and possibly a bottom FormView, or floating ToolBar for user control. To me that sounds the most sophisticted. Having a bunch of Dialog boxes poping up is a little wierd. Are you committed to the MDI?

Hello everyone.
I just wanted to thank you all for your help. I haven't been able to work on that particular part of the problem yet due to more pressing issues but I will get around to it this week and let you know what exactly happened and then mark the thread as resolved.

Emailus, the basically the program loads unknown data from an unknown source vial a Data Abstraction Layer and displays information about it (it's complicated to explain briefly what and how), but it basically indexes data for permanent storage and later reference (sort of). It then takes the unknown data and asks a content handler to display the data if so requested. That is where the embedded dialog or formview idea came from.
When new data is inserted, the insert form generates file filters dynamically based on what content handler DLLs are available.

Maybe that gives you a better idea of what is going on...

Hello folks,

sorry for the late reply, but I finally found time to work on this feature.
Apparently the child dialog inside the main one works wonderfully.

I have one question though about something I haven't gotten to work right yet:
The main window can be resized by the user, or put into fullscreen. That means the child dialog has to get larger, too.
Is it legitimate to send a WM_SIZE message to the child dialog with the new available client area in lParam of the WM_SIZE message?
For example, when the parent gets resized, can I calculate the new available child size and then send the message or could that cause trouble because of DLL boundaries?

Thank you again!

Dll or not, it has nothing to do with resizing. Besides, resizing is done by means of MoveWindow or SetWindowPos APIs, not with WM_SIZE.

MSDN

Quote:

---

WM_SIZE Message

Sent to a window after its size has changed.

---

'Sent to a window' actually means that Windows sends it, not application.

Haha very well ok.
So it is legitimate to call MoveWindow() with the new coordinates relative to the upper right corner of the parent dialog as I understand from the documentation? Even if the child dialog comes from a DLL?

Is that also the best-practice maneuver?