windows resources (dialogs)

Hi,

Can Windows resources (dialogs and strings) be loaded
into Dolphin ?

I am thinking about porting an Actor based app to Dolphin.
I have about 130 dialogs and 10,000 strings embedded in
my current Windows resource files.

Thanks,
Lynn McGuire

Lynn,

> Can Windows resources (dialogs and strings) be loaded
> into Dolphin ?

If I understood what I just browsed, Dolphin knows how to load strings, but,
doesn't appear (and I wouldn't really expect it to) have an obvious way to
load dialog resources.  With that said, I suspect you could get it to do so
fairly easily by passing the correct stuff into
DialogView>>basicCreateAt:extent: - I'll defer to to Andy re how difficult
that would be to do.

One option to consider would be to get the dialogs loaded only to the point
of having a view handle, and then navigate the child controls via the
Windows API to create Dolphin-specific view resources.  You should be able
to subclass my ViewGenerator tool to create the view resources and at least
some code.

Good luck!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Lynn McGuire" <[hidden email]> wrote in message
news:3cd981ab$[hidden email]...
> Hi,
>
> Can Windows resources (dialogs and strings) be loaded
> into Dolphin ?
>
> I am thinking about porting an Actor based app to Dolphin.
> I have about 130 dialogs and 10,000 strings embedded in
> my current Windows resource files.

All dialog's in Dolphin are loaded from a resource template (this is
necessary in order for them to behave 100% correctly as dialogs), but mostly
from one that is empty with the controls being added dynamically after
creation.

Dolphin's walkback dialog (WalkbackDialog) is an example of a dialog that
uses a custom resource template. If you have D5PRO the ImageStripperProgress
dialog is another example, but it is not in the view hierarchy.

You will need to create a subclass of DialogView, and as a bare minimum
override the #resourceLib and #template methods. This should be sufficient
to get the dialog to display, but the controls will not automatically be
subclassed by Dolphin, so most of the usual events will not be generated. An
appropriate place to subclass the controls would be in an override of
#onInitDialog. In order to do this you will need to use
#getItemHandle:ifAbsent: to find the handle of the control with a particular
id, attach a ControlView of the appropriate class, and then send it a
#subclassWindow:

You might be able to automate some of this by navigating the child windows
of the dialog by making use of the EnumChildWindows() API. Actually a tool
that could generate a Dolphin view resource from a dialog template (as Bill
suggests) might make an interesting and useful goodie. Another possibility
would be a tool that generated a DialogView subclass with instance variables
for each control and appropriate code in #onInitDialog to find, subclass
them all, and store into the instance variables.

You may not need to subclass the control's at all, but instead rely on using
messages such as #setItem:text:, which is in fact what WalkbackDialog does.
For 130 dialogs though, this might be a little tedious, and it doesn't allow
for much control.

Loading the strings is straightforward - you can just use String
class>>fromId:in:

Regards

Blair