[Openroad-users] BringtoFront issue on an OR frame

Thu Nov 23 00:48:51 EST 2006

Many thanks for all your valuable suggestions. Unfortunately, the
workarounds using the WindowVisibility attribute, the Activate method or
even using a go-between frame don't seem to work in this scenario - the
.Net form seems to sit on top regardless.

I'll try working on Richard's suggestion of minimising the calling form
(.Net), at least in the short term. But it would be nice if the
BringToFront worked at the windows level, as opposed to just within an
OR environment. Perhaps something for the big boys (n' gals) at Ingres
Corp to consider?

Regards,
Jay

-----Original Message-----
From: Collins, William - ES/EW [mailto:William.Collins at itt.com] 
Sent: 21 November 2006 22:18
To: International OpenROAD Users
Subject: Re: [Openroad-users] BringtoFront issue on an OR frame

I don't know if this will do the trick for you, but I've solved similar
problems with it and it's simple. When your event fires, issue the
BringToFront, followed by a CurFrame.WindowVisibility = WV_ICON, then
CurFrame.WindowVisibility = WV_VISIBLE. In my experience most machines
are so fast now, you can't even see it happen.

Maybe...?
Bill Collins, 
Software Engineering Consultant, 
President, OpenROAD Users International 
Phone: 973-284-3964 

"By now, it should go without saying
that what the oven is to the baker
and the berry-stained blouse to the drycleaner
so the window is to the poet." 
-Billy Collins, two-time Poet Laureate of the U.S.

  _____  

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Antill, Jim
Sent: Tuesday, November 21, 2006 11:00 AM
To: International OpenROAD Users
Subject: Re: [Openroad-users] BringtoFront issue on an OR frame

Jay,

We're doing something similar here, getting an OpenROAD image to display
a frame when it receives an external event. (The event is sent by an
OpenROAD image rather than .Net ).

The problem was that the first frame opened in the receiving
application's session always appeared in the background, despite using
BringToFront. Subsequent frames opened by the receiving application
worked fine, appearing on top as requested. Using the Activate method on
the opened frame initially sorted the problem out, but at the expense of
disturbing other events on the frame. 

Our solution was to open an initial frame in the receiving app during
start up of the sending app. That way the first "real" frame requested
on the receiving app isn't really the first and displays in front
correctly. A bit messy, but that initial frame can also be used to
perform some real startup work as well.

Not identical to what you're doing, but hope that helps a bit.

Regards,
Jim  

-----Original Message-----
From: Richard M. Wright [mailto:Richard.M.Wright at aeroint.com] 
Sent: 21 November 2006 15:44
To: International OpenROAD Users
Subject: Re: [Openroad-users] BringtoFront issue on an OR frame

Jay,

I have also had an issue with this:

I think...  that as your first app is still live then control will
return to it after the event has been handled. This would be the same
effect with using an intermediary (3gl) if the 3gl returns, once that
process has completed. Are you able to minimise, your initial app after
the event has been raised?

Rich

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com]On Behalf Of Mehta, Jay
Sent: 21 November 2006 15:26
To: openroad-users at peerlessit.com
Subject: [Openroad-users] BringtoFront issue on an OR frame

Hi all, 

We've been facing some issues with the BringtoFront functionality,
specifically in the context of an OR userevent that is indirectly
triggered by an action on a VB .Net form. The event is raised and
directed to the receiving OR frame by an intermediate agent, and the
code to then bring that frame to the front is executed as expected (all
this verified by running the application through the debugger). However,
the .Net form that originally triggered the whole sequence of events
still seems to sit on top of the receiving OR frame. We've even tried
using a 3GL call to the SetWindowPos function, to change the order of
the top-level window, but to no avail. 

Currently using OR 4.1/0302 (int.w32/00), Patch 9409 on Windows XP SP1.
Any help would be much appreciated. 

Thanks in advance, 
Jay 

_______________________________________________________

The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken or
omitted to be taken in reliance on it, is prohibited and may be
unlawful. The registered office of Wellington Underwriting plc is 88
Leadenhall Street, London, UK EC3A 3BA.

Wellington Underwriting plc is listed on the London Stock Exchange.

Wellington Underwriting Agencies Limited is authorised and regulated by
the Financial Services Authority.

Wellington Syndicate Services Limited is an Appointed Representative of
Wellington Underwriting Agencies Limited.

_______________________________________________________

************************

This message has been delivered to the Internet by the Revenue Internet
e-mail service

*************************

************************************

This e-mail and any files transmitted with it are proprietary and
intended solely

for the use of the individual or entity to whom they are addressed. If
you have

received this e-mail in error please notify the sender. Please note that
any views

or opinions presented in this e-mail are solely those of the author and
do not

necessarily represent those of ITT, Inc. The recipient should check

this e-mail and any attachments for the presence of viruses. ITT accepts

no liability for any damage caused by any virus transmitted by this
e-mail.

************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://peerlessit.com/pipermail/openroad-users/attachments/20061122/2ef98698/attachment.html 