We have an existing Photon Phab app “V” which runs fine as a standalone
app. It has a single window with several panes and a couple of dialogs.
We are developing a new application “W”. The main window of W will
contain several panes, one of which we want to consist of an instance
of “V”. We don’t really care whether “V” is running as a separate
process or whether it is running as part of the W process, but we do
need all of V’s functionality (callbacks, dialogs etc) to work the same
as they do in the standalone app. And obviously we want V to move and
get minimused (etc) along with W.
V and W are both fixed-size windows.
What is the best way of doing this? Obviously we want to avoid having
to copy/replicate all of V’s code within W.
Should we just spawn V as a child process of W but position it where we
want it to appear and subsequently do “manual” window management of V
so that whenever W is moved or minimised (etc), then V is moved along
with it (using PtForwardWindowTaskEvent() etc). Will this look OK
visually or will V have a noticeable/annoying lag behind W?
Should we re-engineer V as a custom widget?
Is there anything clever we can do by turning V into a DLL which can
somehow be used by W?
Any other possible approaches?
I’m just looking for some ideas on the best way to do this.
Thanks,
Rob Rutherford
Ruzz Technology
On 2006-08-23 10:20:09 +1000, Robert Rutherford
<ruzz@NoSpamPlease.ruzz.com> said:
We have an existing Photon Phab app “V” which runs fine as a standalone
app. It has a single window with several panes and a couple of dialogs.
We are developing a new application “W”. The main window of W will
contain several panes, one of which we want to consist of an instance
of “V”. We don’t really care whether “V” is running as a separate
process or whether it is running as part of the W process, but we do
need all of V’s functionality (callbacks, dialogs etc) to work the same
as they do in the standalone app. And obviously we want V to move and
get minimused (etc) along with W.
After further research (thanks Andy) It seems like using
PtClient/PtServer widgets may be the way to go.
Anyone have any experience (good or bad) with this approach?
Rob Rutherford
Robert Rutherford wrote:
On 2006-08-23 10:20:09 +1000, Robert Rutherford
ruzz@NoSpamPlease.ruzz.com> > said:
We have an existing Photon Phab app “V” which runs fine as a
standalone app. It has a single window with several panes and a couple
of dialogs.
We are developing a new application “W”. The main window of W will
contain several panes, one of which we want to consist of an instance
of “V”. We don’t really care whether “V” is running as a separate
process or whether it is running as part of the W process, but we do
need all of V’s functionality (callbacks, dialogs etc) to work the
same as they do in the standalone app. And obviously we want V to move
and get minimused (etc) along with W.
After further research (thanks Andy) It seems like using
PtClient/PtServer widgets may be the way to go.
Anyone have any experience (good or bad) with this approach?
It might be simpler to turn “V” into a dll. The setup of a
PtClient/PtServer pair is somewhat more complicated. And PtClient has a
few limitations – for instance, your “V” should never never attempt
to destroy, unrealize, or even resize its PtServer, because those
operations should be controlled by the PtClient. (You’ll need to
register a DESTROYED callback to tell you when the PtClient asks your
PtServer to self-destruct.) Also, any widgets you put in the same
window in front of your PtClient will stay behind its PtServer. And
keyboard focus might not always work seamlessly when you try to tab into
or out of the PtServer.
On 2006-08-24 05:38:28 +1000, Wojtek Lerch <Wojtek_L@yahoo.ca> said:
Robert Rutherford wrote:
On 2006-08-23 10:20:09 +1000, Robert Rutherford
ruzz@NoSpamPlease.ruzz.com> > said:
We have an existing Photon Phab app “V” which runs fine as a standalone
app. It has a single window with several panes and a couple of dialogs.
We are developing a new application “W”. The main window of W will
contain several panes, one of which we want to consist of an instance
of “V”. We don’t really care whether “V” is running as a separate
process or whether it is running as part of the W process, but we do
need all of V’s functionality (callbacks, dialogs etc) to work the same
as they do in the standalone app. And obviously we want V to move and
get minimused (etc) along with W.
It might be simpler to turn “V” into a dll.
Thanks Wojtek.
Can you elaborate a bit on how this would work? I’ve read the section
in the docs on “Making a DLL out of a PhAB application” but I don’t
quite get how to do this in practice. For example, how do I tell the
DLL (V) app what region to use in my main app?
Is there an example anywhere?
Rob Rutherford
Robert Rutherford wrote:
On 2006-08-24 05:38:28 +1000, Wojtek Lerch <> Wojtek_L@yahoo.ca> > said:
It might be simpler to turn “V” into a dll.
Can you elaborate a bit on how this would work? I’ve read the section in
the docs on “Making a DLL out of a PhAB application” but I don’t quite
get how to do this in practice. For example, how do I tell the DLL (V)
app what region to use in my main app?
Since the DLL becomes part of the same process, you can forget about
regions – you can use widget pointers. With error checking removed for
clarity, this can be as simple as
/// In the main program:
void *handle = dlopen( path, 0 )
int (entrypnt)() = ((int()()) dlsym( handle, “myentrypoint” );
(*entrypnt)( path, ABW_dll_pane );
/// In the DLL:
int myentrypoint( const char *path, PtWidget_t *panewgt ) {
ApAddContext( &AbContext, path );
ApCreateModule( ABM_dll_contents, panewgt, NULL );
}
On 2006-08-25 00:42:31 +1000, Wojtek Lerch <Wojtek_L@yahoo.ca> said:
Robert Rutherford wrote:
On 2006-08-24 05:38:28 +1000, Wojtek Lerch <> Wojtek_L@yahoo.ca> > said:
It might be simpler to turn “V” into a dll.
Can you elaborate a bit on how this would work? I’ve read the section
in the docs on “Making a DLL out of a PhAB application” but I don’t
quite get how to do this in practice. For example, how do I tell the
DLL (V) app what region to use in my main app?
Since the DLL becomes part of the same process, you can forget about
regions – you can use widget pointers. With error checking removed
for clarity, this can be as simple as
/// In the main program:
void *handle = dlopen( path, 0 )
int (entrypnt)() = ((int()()) dlsym( handle, “myentrypoint” );
(*entrypnt)( path, ABW_dll_pane );
/// In the DLL:
int myentrypoint( const char *path, PtWidget_t *panewgt ) {
ApAddContext( &AbContext, path );
ApCreateModule( ABM_dll_contents, panewgt, NULL );
}
Thanks Wojtek - excellent 
Steve if you’re watching it might be nice to add this example to the
section in the docs on “Making a DLL out of a PhAB application”.
Rob Rutherford
Robert Rutherford <ruzz@nospamplease.ruzz.com> wrote:
Steve if you’re watching it might be nice to add this example to the
section in the docs on “Making a DLL out of a PhAB application”.
I’m always watching. I’ll pass this along to Drew. Thanks for the
suggestion.
Steve Reid stever@qnx.com
Technical Editor
QNX Software Systems
On 2006-08-24 05:38:28 +1000, Wojtek Lerch <Wojtek_L@yahoo.ca> said:
Robert Rutherford wrote:
On 2006-08-23 10:20:09 +1000, Robert Rutherford
ruzz@NoSpamPlease.ruzz.com> > said:
We have an existing Photon Phab app “V” which runs fine as a standalone
app. It has a single window with several panes and a couple of dialogs.
We are developing a new application “W”. The main window of W will
contain several panes, one of which we want to consist of an instance
of “V”. We don’t really care whether “V” is running as a separate
process or whether it is running as part of the W process, but we do
need all of V’s functionality (callbacks, dialogs etc) to work the same
as they do in the standalone app. And obviously we want V to move and
get minimused (etc) along with W.
After further research (thanks Andy) It seems like using
PtClient/PtServer widgets may be the way to go.
We ended up deciding to go with the PtClient/PtServer pair as it gave
us better de-coupling between the apps, and it gave us (we thought) the
opportunity for the PtServer to be running on a different node to the
PtClient.
However it seems that the PtClient and PtServer pair actually must run
in the same Photon session.
Is this correct? Is there not any way to have the PtServer running in a
different Photon session (potentially on a different machine)?
In this case, what is the meaning/relevance of the
Pt_CB_SERVER_TRANSPORT callback on the PtServer widget?
Rob Rutherford
Ruzz Technology
Robert Rutherford wrote:
However it seems that the PtClient and PtServer pair actually must run
in the same Photon session.
Yes; the problem is that PtServer uses PtAppAddInput(), which doesn’t
allow it to specify a remote process.
Is this correct? Is there not any way to have the PtServer running in a
different Photon session (potentially on a different machine)?
The two processes must be both connected to the same Photon session.
The goal is for them to be able to display in the same window, isn’t it?
There’s no requirement that your two processes must be running on the
same machine that their Photon server is running on.
In this case, what is the meaning/relevance of the
Pt_CB_SERVER_TRANSPORT callback on the PtServer widget?
This callback is called when the PtServer notices that the Photon
session that its PtClient is being realized on doesn’t seem to match the
one that the PtServer is connected to. (The detection is done by a
simple strcmp(), and you might get a false positive e.g. when one of the
processes connected to Photon using a full /net/machine/dev/photon path).
Since the two processes initially find each other by talking to their
Photon server, this can only happen if the client subsequently calls
PtReattach() to “transport” itself to another Photon. In QNX4, a user
could cause that by using the “jumpgate” mechanism; QNX6 doesn’t come
with a UI to “transport” a running application to a different Photon,
and you don’t have to worry about it unless you put a PtReattach() call
in your code yourself.
The purpose of the callback is to let the server process re-attach
itself to the client’s new Photon session before the PtServer attempts
to realize itself. There’s no clean way to tell the PtClient that your
server doesn’t want to get transported – probably the best you can do
is destroy your PtServer widget, and have code in the client to look for
or spawn a new server process.
On 2006-09-19 04:52:05 +1000, Wojtek Lerch <Wojtek_L@yahoo.ca> said:
Is this correct? Is there not any way to have the PtServer running in a
different Photon session (potentially on a different machine)?
The two processes must be both connected to the same Photon session.
The goal is for them to be able to display in the same window, isn’t it?
There’s no requirement that your two processes must be running on the
same machine that their Photon server is running on.
Hi Wojtek,
We have spent some time trying to make this work, but without joy.
We have the standard ptclient/ptserver example from the Photon training
course. It doesn’t matter what we do, we can only make it work if the
Photon session and both client and server programs are all on the same
machine.
Eg we have tried
On machine AA:
ptserver
On machine BB:
ptclient -s /net/AA/dev/photon
We have also tried
On machine AA:
ptserver -s /net/BB/dev/photon
On machine BB:
ptclient
We have even tried:
On machine AA:
ptserver -s /net/CC/dev/photon
On machine BB:
ptclient -s /net/CC/dev/photon
None of these work. The only case that works is client, server, and
Photon session are all on the sam machine. We have also tried setting
the PHOTON environment variable rather than using the -s command line
argument.
In all cases, the client is unable to connect to the server.
Are we missing something, is this not supported, or is there a bug?
Rob Rutherford
Ruzz Technology
Robert Rutherford wrote:
None of these work. The only case that works is client, server, and
Photon session are all on the sam machine. We have also tried setting
the PHOTON environment variable rather than using the -s command line
argument.
In all cases, the client is unable to connect to the server.
Are we missing something, is this not supported, or is there a bug?
Indeed, there seems to be a bug. The easiest way to reproduce is by
running something like
$ helpviewer -s /net/wojtek/dev/photon
I just had a quick look at the code and it didn’t find anything
obviously wrong with it. I’ll add it to our bug database and hopefully
it’ll be investigated…
On 2006-09-27 05:33:24 +1000, Wojtek Lerch <Wojtek_L@yahoo.ca> said:
Indeed, there seems to be a bug. The easiest way to reproduce is by
running something like
$ helpviewer -s /net/wojtek/dev/photon
I just had a quick look at the code and it didn’t find anything
obviously wrong with it. I’ll add it to our bug database and hopefully
it’ll be investigated…
Thanks Wojtek. This is fairly significant for us so I will try to
escalate this through our sales channel. Can you let me know the PR
number?
Rob Rutherford