phrelay timeout

bridged with qdn.public.qnx4.photon
server

phrelay timeout

Post by server » Thu Oct 12, 2000 6:10 am

message unavailable

Karsten Hoffmann

Re: phrelay timeout

Post by Karsten Hoffmann » Thu Oct 12, 2000 6:10 am

[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

Garry Turcotte

Re: Citrix ICA problems

Post by Garry Turcotte » Thu Oct 12, 2000 3:47 pm

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.

Alex Cellarius

Re: Citrix ICA problems

Post by Alex Cellarius » Fri Oct 13, 2000 7:19 pm

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.

Garry Turcotte

Re: Citrix ICA problems

Post by Garry Turcotte » Mon Oct 16, 2000 2:13 pm

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.

Karsten P. Hoffmann

Re: phrelay timeout

Post by Karsten P. Hoffmann » Wed Nov 08, 2000 8:31 am

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

Garry Turcotte

Re: phrelay timeout

Post by Garry Turcotte » Fri Nov 10, 2000 4:32 pm

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.

Karsten P. Hoffmann

Re: phrelay timeout

Post by Karsten P. Hoffmann » Wed Nov 15, 2000 7:51 am

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

Karsten P. Hoffmann

Re: phrelay timeout

Post by Karsten P. Hoffmann » Wed Nov 15, 2000 8:07 am


Garry Turcotte

Re: phrelay timeout

Post by Garry Turcotte » Wed Nov 15, 2000 8:36 pm

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:

1. 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.

Karsten P. Hoffmann

Re: phrelay timeout

Post by Karsten P. Hoffmann » Thu Nov 16, 2000 1:27 pm

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

Karsten Hoffmann

Re: bypassing login

Post by Karsten Hoffmann » Tue Nov 21, 2000 7:34 am

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 <username>" -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

Jim

Re: Windows

Post by Jim » Mon Mar 26, 2001 5:00 pm

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


Markus Jauslin

Re: Windows

Post by Markus Jauslin » Wed Mar 28, 2001 9:59 am

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>...
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




Markus Jauslin

Re: Windows

Post by Markus Jauslin » Thu Mar 29, 2001 6:38 am

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>...
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






Post Reply

Return to “qdn.public.qnx4.photon”