message unavailable
[continued from qdn.public.photon due to NG changes]
Garry Turcotte wrote:
Could you add a bunch more -V’s to the command line for phrelay
and send me the complete log files?
Answered per personal email!
Results will be posted here anyway (if any 
)
–
| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld
In article <39E4C850.D27EA69A@systems104.co.za>,
Alex Cellarius <acellarius@systems104.co.za> wrote:
Any opinions on this one?
Also-the other possible bugs mentioned in the other post?Alex Cellarius wrote:
Garry Turcotte wrote:
2. There is no option, or no dialog to configure server farm
connections, like server groups (primary and backup)This is under Options, and allows the user to enter specific
known servers (rather than just a broadcast address).
These servers are also polled for Published Application on
the previous screen.Would it be possible to add the dialog to add additional servers
as well?
Sorry, this capability is not in our current source base.
–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.
Garry Turcotte wrote:
…
Would it be possible to add the dialog to add additional servers
as well?Sorry, this capability is not in our current source base.
–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.
OK.
Any progress on the other issues?
-apparent bug with published applications as described earlier?
(This one is a big BIG showstopper here…)
-apparent bug where a blank line can be added to the list of
servers, and which is difficult to get rid of.
In article <39E77C56.560C5AEE@systems104.co.za>,
Alex Cellarius <acellarius@systems104.co.za> wrote:
Garry Turcotte wrote:
…Would it be possible to add the dialog to add additional servers
as well?Sorry, this capability is not in our current source base.
–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.OK.
Any progress on the other issues?
-apparent bug with published applications as described earlier?
(This one is a big BIG showstopper here…)
-apparent bug where a blank line can be added to the list of
servers, and which is difficult to get rid of.
We have a developer assigned to Icamgr.
Expect a status report shortly…
–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.
Previously, Karsten Hoffmann wrote in qdn.public.qnx4.photon:
[continued from qdn.public.photon due to NG changes]
Garry Turcotte wrote:
Could you add a bunch more -V’s to the command line for phrelay
and send me the complete log files?Answered per personal email!
Results will be posted here anyway (if any >
Is still somebody taking care about this?
–
| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld
In article <Voyager.001108093105.23744A@qnx-node9.mbs>,
Karsten P. Hoffmann <Karsten.Hoffmann@mbs-software.de> wrote:
Previously, Karsten Hoffmann wrote in qdn.public.qnx4.photon:
[continued from qdn.public.photon due to NG changes]Garry Turcotte wrote:
Could you add a bunch more -V’s to the command line for phrelay
and send me the complete log files?Answered per personal email!
Results will be posted here anyway (if any >
Is still somebody taking care about this?
Yes. You’ll be the first to know when we find it
–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.
Previously, Karsten Hoffmann wrote in qdn.public.qnx4.photon:
[continued from qdn.public.photon due to NG changes]
Garry Turcotte wrote:
Could you add a bunch more -V’s to the command line for phrelay
and send me the complete log files?Answered per personal email!
Results will be posted here anyway (if any >
I
–
| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld
In article <Voyager.001115090718.13042C@qnx-node9.mbs>,
Karsten P. Hoffmann <Karsten.Hoffmann@mbs-software.de> wrote:
-=-=-=-=-=-
Please excuse my previous almost empty posting - just hit the wrong key >
Previously, Karsten Hoffmann wrote in qdn.public.qnx4.photon:
[continued from qdn.public.photon due to NG changes]Garry Turcotte wrote:
Could you add a bunch more -V’s to the command line for phrelay
and send me the complete log files?Some more information:
- The time between starting phrelay and Photon seem to be exactly
10 seconds.[snip]
It’s exactly 10 seconds (1+2+3+4) [sigh]
Sorry for the delay in finding this (I didn’t own phrelay
2 years ago) the bug was only in a temporary version of one
of the source files, and was fixed almost 2 year ago,
unfortunately the build tag slipped…
–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.
Previously, Garry Turcotte wrote in qdn.public.qnx4.photon:
Sorry for the delay in finding this (I didn’t own phrelay
2 years ago) the bug was only in a temporary version of one
of the source files, and was fixed almost 2 year ago,
unfortunately the build tag slipped…
I know that kind of problems )
What about a pre-release to calm our customers?
TIA,
Karsten.
–
| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld
Ross Brantner wrote:
I have used export LOGNAME=xxx to allow me to bypass the phlogin but I
would really like to log a specific user in. Any ideas on this one? I
looked at the manual for phlogin but could not figure out how to log on a
particular user. Any help would be greatly appreciated. Thanks.
You can do a forced, regular login within your sysinit like this:
tinit -c "login -p -f " -t /dev/con1 &
and then you can start Photon from the user’s profile!
HTH,
Karsten.
–
| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld
Markus,
I don’t know if this is what you want to do, but what I do to allow my
windows and dialogs to be clickable to front as well as be able to move
behind other windows and dialogs, is that I ReParent them to NULL. This in
effect causes them to be primary windows and a taskbar button will be
created for them. But, it solved my problem with how windows should behave
in regards to front/back positioning. Here is the statement that I use.
Status = PtReParentWidget( *wgt, NULL );
The key part of the above statment is the NULL. Look at the help for more
information.
Hope this helps.
Jim
Markus Jauslin wrote in message <99n6dj$bfu$1@inn.qnx.com>…
Hallo
The Programmer’s Guide writes in the chapter “Managing multiple windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child window is
always in front of its parent. The child windows can move above and below
siblings. For windows to be able to go behind other windows, they must be
siblings.
So for a window to be able to move behind the base window, that window
would
have to have no parent.Now I have the base window with two child dialogs (D_a and D_b) which my
overlapp. D_a has another dialog as child D_c. Now the problem is that when
there is no dialog D_c, I can select if dialog D_a or D_b should be top
front. If dialog D_c is created it will be in front but once when D_b has
be
clicked to front D_c stays covered by D_b.As I understand the programmer’s guide this is not intended. Am I wrong?
Can
someone offer a work around until a possible fix will be available.Thanks a lot
Markus
The problem with this approach is that the child dialogs may be covered by
the base window or by parent dialogs which is in our case an undesired
behavior. Our system should be managable by touch screen and somehow
unpredictable dialog orders should be avoided so computer untrained people
dont’t get confused. The only little exception is the dialog D_b which
contains alarms and error messages.
So thank you for hint and I appreciate more of them.
Markus
Jim <jmomeyer@nyab.com> schrieb in im Newsbeitrag:
99nasv$e9t$1@inn.qnx.com…
Markus,
I don’t know if this is what you want to do, but what I do to allow my
windows and dialogs to be clickable to front as well as be able to move
behind other windows and dialogs, is that I ReParent them to NULL. This
in
effect causes them to be primary windows and a taskbar button will be
created for them. But, it solved my problem with how windows should
behave
in regards to front/back positioning. Here is the statement that I use.Status = PtReParentWidget( *wgt, NULL );
The key part of the above statment is the NULL. Look at the help for more
information.Hope this helps.
Jim
Markus Jauslin wrote in message <99n6dj$bfu$> 1@inn.qnx.com> >…
HalloThe Programmer’s Guide writes in the chapter “Managing multiple windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child window is
always in front of its parent. The child windows can move above and below
siblings. For windows to be able to go behind other windows, they must be
siblings.
So for a window to be able to move behind the base window, that window
would
have to have no parent.Now I have the base window with two child dialogs (D_a and D_b) which my
overlapp. D_a has another dialog as child D_c. Now the problem is that
when
there is no dialog D_c, I can select if dialog D_a or D_b should be top
front. If dialog D_c is created it will be in front but once when D_b has
be
clicked to front D_c stays covered by D_b.As I understand the programmer’s guide this is not intended. Am I wrong?
Can
someone offer a work around until a possible fix will be available.Thanks a lot
Markus
\
Here is another piece of information: The alarm dialog D_b can be put behind
dialog D_c by pressing Alt-F3. What’s missing is that dialog D_c can pe
clicked to front.
Markus Jauslin <markus.jauslin@ch.mullermartini.com> schrieb in im
Newsbeitrag: 99rr32$i7t$1@inn.qnx.com…
The problem with this approach is that the child dialogs may be covered by
the base window or by parent dialogs which is in our case an undesired
behavior. Our system should be managable by touch screen and somehow
unpredictable dialog orders should be avoided so computer untrained people
dont’t get confused. The only little exception is the dialog D_b which
contains alarms and error messages.
So thank you for hint and I appreciate more of them.
Markus
Jim <> jmomeyer@nyab.com> > schrieb in im Newsbeitrag:
99nasv$e9t$> 1@inn.qnx.com> …
Markus,I don’t know if this is what you want to do, but what I do to allow my
windows and dialogs to be clickable to front as well as be able to move
behind other windows and dialogs, is that I ReParent them to NULL. This
in
effect causes them to be primary windows and a taskbar button will be
created for them. But, it solved my problem with how windows should
behave
in regards to front/back positioning. Here is the statement that I use.Status = PtReParentWidget( *wgt, NULL );
The key part of the above statment is the NULL. Look at the help for
more
information.Hope this helps.
Jim
Markus Jauslin wrote in message <99n6dj$bfu$> 1@inn.qnx.com> >…
HalloThe Programmer’s Guide writes in the chapter “Managing multiple
windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child window
is
always in front of its parent. The child windows can move above and
below
siblings. For windows to be able to go behind other windows, they must
be
siblings.
So for a window to be able to move behind the base window, that window
would
have to have no parent.Now I have the base window with two child dialogs (D_a and D_b) which
my
overlapp. D_a has another dialog as child D_c. Now the problem is that
when
there is no dialog D_c, I can select if dialog D_a or D_b should be top
front. If dialog D_c is created it will be in front but once when D_b
has
be
clicked to front D_c stays covered by D_b.As I understand the programmer’s guide this is not intended. Am I
wrong?
Can
someone offer a work around until a possible fix will be available.Thanks a lot
Markus
\
Hallo
The Programmer’s Guide writes in the chapter “Managing multiple windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child window is
always in front of its parent. The child windows can move above and below
siblings. For windows to be able to go behind other windows, they must be
siblings.
So for a window to be able to move behind the base window, that window would
have to have no parent.
Now I have the base window with two child dialogs (D_a and D_b) which may
overlapp. D_a has another dialog as child D_c. Now the problem is that when
there is no dialog D_c, I can select if dialog D_a or D_b should be top
front. If dialog D_c is created it will be in front but once when D_b has be
clicked to front D_c stays covered by D_b. This can be changed only by
pressing Alt-F3 on dialog D_b.
As I understand the programmer’s guide this is not intended. Am I wrong? Can
someone offer a work around until a possible fix will be available.
Thanks a lot
Markus
The version used us QNX 4.25 and Photon 1.14 Patch C from May 2001 CD.
“Markus Jauslin” <markus.jauslin@ch.mullermartini.com> schrieb im
Newsbeitrag news:99u3lg$ra$1@inn.qnx.com…
Here is another piece of information: The alarm dialog D_b can be put
behind
dialog D_c by pressing Alt-F3. What’s missing is that dialog D_c can pe
clicked to front.
Markus Jauslin <> markus.jauslin@ch.mullermartini.com> > schrieb in im
Newsbeitrag: 99rr32$i7t$> 1@inn.qnx.com> …
The problem with this approach is that the child dialogs may be covered
by
the base window or by parent dialogs which is in our case an undesired
behavior. Our system should be managable by touch screen and somehow
unpredictable dialog orders should be avoided so computer untrained
people
dont’t get confused. The only little exception is the dialog D_b which
contains alarms and error messages.
So thank you for hint and I appreciate more of them.
Markus
Jim <> jmomeyer@nyab.com> > schrieb in im Newsbeitrag:
99nasv$e9t$> 1@inn.qnx.com> …
Markus,I don’t know if this is what you want to do, but what I do to allow my
windows and dialogs to be clickable to front as well as be able to
move
behind other windows and dialogs, is that I ReParent them to NULL.
This
in
effect causes them to be primary windows and a taskbar button will be
created for them. But, it solved my problem with how windows should
behave
in regards to front/back positioning. Here is the statement that I
use.Status = PtReParentWidget( *wgt, NULL );
The key part of the above statment is the NULL. Look at the help for
more
information.Hope this helps.
Jim
Markus Jauslin wrote in message <99n6dj$bfu$> 1@inn.qnx.com> >…
HalloThe Programmer’s Guide writes in the chapter “Managing multiple
windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child
window
is
always in front of its parent. The child windows can move above and
below
siblings. For windows to be able to go behind other windows, they
must
be
siblings.
So for a window to be able to move behind the base window, that
window
would
have to have no parent.Now I have the base window with two child dialogs (D_a and D_b) which
my
overlapp. D_a has another dialog as child D_c. Now the problem is
that
when
there is no dialog D_c, I can select if dialog D_a or D_b should be
top
front. If dialog D_c is created it will be in front but once when D_b
has
be
clicked to front D_c stays covered by D_b.As I understand the programmer’s guide this is not intended. Am I
wrong?
Can
someone offer a work around until a possible fix will be available.Thanks a lot
Markus
\
Hi Markus,
I have spoken with one of the developers and here is his suggestions:
My first guess would be that D_c is not really a child of D_a. It seems
to be a common misconception that if a dialog is created by another
dialog’s callback, it automatically becomes the other dialog’s child.
That’s not true: a newly created dialog or window module becomes the
child of the base window unless you call ApModuleParent() to set up the
module’s parent and then create the module using ApCreateModule()
Hope this helps
Regards
Brenda
Markus Jauslin <markus.jauslin@ch.mullermartini.com> wrote:
Hallo
The Programmer’s Guide writes in the chapter “Managing multiple windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child window is
always in front of its parent. The child windows can move above and below
siblings. For windows to be able to go behind other windows, they must be
siblings.
So for a window to be able to move behind the base window, that window would
have to have no parent.Now I have the base window with two child dialogs (D_a and D_b) which may
overlapp. D_a has another dialog as child D_c. Now the problem is that when
there is no dialog D_c, I can select if dialog D_a or D_b should be top
front. If dialog D_c is created it will be in front but once when D_b has be
clicked to front D_c stays covered by D_b. This can be changed only by
pressing Alt-F3 on dialog D_b.As I understand the programmer’s guide this is not intended. Am I wrong? Can
someone offer a work around until a possible fix will be available.Thanks a lot
Markus
Hi Brenda,
“Gui Group” <gui@qnx.com> schrieb im Newsbeitrag
news:9j1m06$obe$4@nntp.qnx.com…
Hi Markus,
I have spoken with one of the developers and here is his suggestions:
My first guess would be that D_c is not really a child of D_a. It seems
to be a common misconception that if a dialog is created by another
dialog’s callback, it automatically becomes the other dialog’s child.
That’s not true: a newly created dialog or window module becomes the
child of the base window unless you call ApModuleParent() to set up the
module’s parent and then create the module using ApCreateModule()
I did already know of that fact and took care of this. In every setup
function of a dialog I call PtReparent( link_instance, ParentDialog ). So
I’m sure that D_c is a child of D_a.
Markus
Markus Jauslin <> markus.jauslin@ch.mullermartini.com> > wrote:
HalloThe Programmer’s Guide writes in the chapter “Managing multiple
windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child window
is
always in front of its parent. The child windows can move above and
below
siblings. For windows to be able to go behind other windows, they must
be
siblings.
So for a window to be able to move behind the base window, that window
would
have to have no parent.Now I have the base window with two child dialogs (D_a and D_b) which
may
overlapp. D_a has another dialog as child D_c. Now the problem is that
when
there is no dialog D_c, I can select if dialog D_a or D_b should be top
front. If dialog D_c is created it will be in front but once when D_b
has be
clicked to front D_c stays covered by D_b. This can be changed only by
pressing Alt-F3 on dialog D_b.As I understand the programmer’s guide this is not intended. Am I wrong?
Can
someone offer a work around until a possible fix will be available.Thanks a lot
Markus
\
Hi Markus,
Could you post a small sample application that shows this problem
and I will pass it on to one of the developers to look at.
Regards
Brenda
Markus Jauslin <markus.jauslin@ch.mullermartini.com> wrote:
Hi Brenda,
“Gui Group” <> gui@qnx.com> > schrieb im Newsbeitrag
news:9j1m06$obe$> 4@nntp.qnx.com> …
Hi Markus,I have spoken with one of the developers and here is his suggestions:
My first guess would be that D_c is not really a child of D_a. It seems
to be a common misconception that if a dialog is created by another
dialog’s callback, it automatically becomes the other dialog’s child.
That’s not true: a newly created dialog or window module becomes the
child of the base window unless you call ApModuleParent() to set up the
module’s parent and then create the module using ApCreateModule()
I did already know of that fact and took care of this. In every setup
function of a dialog I call PtReparent( link_instance, ParentDialog ). So
I’m sure that D_c is a child of D_a.Markus
Markus Jauslin <> markus.jauslin@ch.mullermartini.com> > wrote:
HalloThe Programmer’s Guide writes in the chapter “Managing multiple
windows”:
If your application has more than one window, you’ll need to take the
relationships between them into account. By definition, a child window
is
always in front of its parent. The child windows can move above and
below
siblings. For windows to be able to go behind other windows, they must
be
siblings.
So for a window to be able to move behind the base window, that window
would
have to have no parent.Now I have the base window with two child dialogs (D_a and D_b) which
may
overlapp. D_a has another dialog as child D_c. Now the problem is that
when
there is no dialog D_c, I can select if dialog D_a or D_b should be top
front. If dialog D_c is created it will be in front but once when D_b
has be
clicked to front D_c stays covered by D_b. This can be changed only by
pressing Alt-F3 on dialog D_b.As I understand the programmer’s guide this is not intended. Am I wrong?
Can
someone offer a work around until a possible fix will be available.Thanks a lot
Markus
\