Can I just say how flipping fantastic Elevate WebBuilder is? The sheer power one
gets in an easy to understand language is amazing, and I'm sure I'd never be able
to do it in raw javascript, at least as reliably.

fwait_tfrmwait.$p.tfrmwait_frmwaitshow = function(sender)
{
  var $t = this;
fmain_frmjoin.tfrmjoin_m_pfnviewernotify = function(noption, szinfo) {
fwait_tfrmwait.$p.tfrmwait_viewernotify.call($t, noption, szinfo); };
};

fwait_tfrmwait.$p.tfrmwait_viewernotify = function(noption, szinfo)
{
  var $t = this;
  if (noption == 0)
     $t.tfrmwait_lblstatus.tlabelcontrol_setcaption(szinfo);
};

from:

procedure TfrmWait.frmWaitShow(Sender: TObject);
begin
   frmJoin.ViewerNotify := ViewerNotify;
end;

And it just works - the main form is able to send notifications to whatever form is
showing. Stunning.

/Matthew Jones/

Matthew,

<< Can I just say how flipping fantastic Elevate WebBuilder is? The sheer
power one gets in an easy to understand language is amazing, and I'm sure
I'd never be able to do it in raw javascript, at least as reliably. >>

Thanks, but just keep in mind that the generated JS from EWB is a bit wonky
compared to hand-coded JS, primarily due to how it needs the JS to be for
scope/namespace isolation and compression.

But yes, in general JS is hard often very hard to read, especially coming
from Object Pascal.

Tim Young
Elevate Software
www.elevatesoft.com

>>Can I just say how flipping fantastic Elevate WebBuilder is? The sheer power one
>>gets in an easy to understand language is amazing, and I'm sure I'd never be able
>>to do it in raw javascript, at least as reliably.

Working with a team of JS guys, I can certainly tell you that there are elements of EWB that make them literally green with envy. Furthermore, EWB 2 has the potential to remove yet another big chunk of their remaining advantage.

>>procedure TfrmWait.frmWaitShow(Sender: TObject);
>>begin
>>    frmJoin.ViewerNotify := ViewerNotify;
>>end;

I'm interested to understand a little more about what you're doing here. I also push messages from form to form, but your method seems too easy! Can you elaborate a little?

Cheers
Mark

> >>procedure TfrmWait.frmWaitShow(Sender: TObject);
> >>begin
> >>    frmJoin.ViewerNotify := ViewerNotify;
> >>end;
>
> I'm interested to understand a little more about what you're doing
> here. I also push messages from form to form, but your method seems
> too easy! Can you elaborate a little?

Basically, I have my main form do the communications with the server, and have
embedded forms show the interactive parts. I needed to be able to send the current
"child" form information, like the user's name, and comms status, without having to
do it on a form by form basis. (No if currentForm is ThisForm then
thisForm.UpdateName). Thus I have it so that the FormShow sets a property on the
main form for the ViewerNotify procedure, and the main form just calls that. The
first parameter is a number to say what it is that is being sent, and the second is
a string for the data (could be plain, or JSON). And of course if the form doesn't
care about the user's name, then it just ignores that notification, which means it
is extensible without me having to change all the forms.

/Matthew Jones/

>>Basically, I have my main form do the communications with the server, and have
>>embedded forms show the interactive parts. I needed to be able to send the current
>>"child" form information, like the user's name, and comms status, without having to
>>do it on a form by form basis. (No if currentForm is ThisForm then
>>thisForm.UpdateName). Thus I have it so that the FormShow sets a property on the
>>main form for the ViewerNotify procedure, and the main form just calls that. The
>>first parameter is a number to say what it is that is being sent, and the second is
>>a string for the data (could be plain, or JSON). And of course if the form doesn't
>>care about the user's name, then it just ignores that notification, which means it
>>is extensible without me having to change all the forms.

Got it. Do the child forms communicate back to the Main form? If so, how do you handle circular references? Presumably method pointers?

The child form knows the main form by its frmMain "global". The main form knows all
the child form details, but I don't want the various parts to have to know which is
active at the current moment, hence the "callback" property.

/Matthew Jones/