My suggestion would be to capture the exitcode and pop up a new dialog box and use AUI_IMAGE to display the image inside it. Then you don't have to worry about making space for it on the screen, and there no conflict with anything else already there. They just close the popup box and then re-enter the tree. The sample program XTRA7 sample program illustrates this. (Note that you need to download and possibly edit the XTRA7.CSV file, and one or more of the images that go with it.)

OK - I will try that technique first and let you know how it works out.

A normal dialog box is modal, meaning that it puts the application in a mode where only that dialog box has the focus. If you want to have dialog boxes that don't monopolize the focus, then you can add MBF_MODELESS to the AUI_CONTROL call creating the dialog to make the dialogs modeless (i.e. not monopolizing the focus). A couple of complications that introduces though:

• Unlike modal dialogs, modeless dialogs do not become the default parent for any subsequent controls. So you have to make sure to specify the parentid parameter in any AUI_CONTROL calls to add controls to the modeless dialog.
• Even that won't work for AUI_IMAGE calls, because it doesn't support the parentid parameter.
• So, you can either switch to MBF_STATIC+MBF_BITMAP controls (which also support image display)
• Or, use MX_AUTOPARENT to explicity make the modeless dialog the parent prior to your AUI_IMAGE calls.

Note that if using the last approach, you have to make sure to clear the MX_AUTOPARENT status before you close the modeless dialog (or right after your AUI_IMAGE calls), lest you end up with a non-existent auto-parent condition, which is liable to cause some kind of spinning wheel condition.

One further complication: aside from making the dialog(s) modeless, you also need to make sure your input/event processing can support click events (or exitcodes) from both the XTREE and the image dialog(s). So waiting in something like ACCEPN for the user to click ESC isn't going to work unless you add logic to also detect the click event to go back into the XTREE, as well as the exitcode events coming out of it. The only practical way to do that is to use AUI_EVENTWAIT with a switch inside a loop to organize all the possible events to be simultaneously managed across the various dialogs.)

I posted a new variation of the XTRA7 sample (XTRA7ML) that allows you to click on multiple images in the tree, each one then getting enlarged in its own modeless dialog. You can drag the dialogs around and return to editing the tree while the dialogs are open. Note that in this example, I decided it wasn't necessary to use AUI_EVENTWAIT since XTREE can perform that function for us. (The one catch is that after displaying an image dialog, the program has to re-enter the tree so that the tree can act as the event coordinator.)

Hi guys,
The problem with modal dialogs is that you can get it hidden behind the parent dialog and the program become apparently unresponsive.
On the other hand, besides modeless dialogs can grow indefinitely, are much better to compare images.
But, if compare pictures is not the goal here, in my opinion, a better approach would be to put the XTREE on the left side of the dialog, oversize the dialog to the right and display the picture there.
With this technique, you can scroll around the XTREE and update the image automatically when the row changes.
Depending on the available area to the right of the xtree, if the image is not enough big, you can still open a dialog with a bigger one, clicking on the image displayed on the right.

Have fun

I haven't run into that problem yet but will look out for it. I have the images all displaying and clearing the way I want to but it deserves more testing. Thanks Jorge. I will see you soon.