[Openroad-users] BringtoFront issue on an OR frame

Thu Nov 23 20:34:32 EST 2006

It is probably a dumb question, but does your .Net application use an
"ALLWAYS ON TOP" like attribute?

Regards

Chris Wallace

Management Information Systems (WA) Pty Ltd
Level 9, MIS House
231 Adelaide Terrace, PERTH  WA  6000
Ph: (08) 9221-9221  Fax: (08) 9221-9224
Email: chrisw at miswa.com.au <mailto:chrisw at miswa.com.au> 
Web: http://www.miswa.com.au

Disclaimer <http://www.miswa.com.audisclaimer/> :  Management
Information Systems (MIS)
This e-mail is private and confidential. If you are not the intended
recipient, please advise us by return e-mail immediately, and delete the
e-mail and any attachments without using or disclosing the contents in
any way. The views expressed in this e-mail are those of the author, and
do not represent those of MIS unless this is clearly indicated.  You
should scan this e-mail and any attachments for viruses.  MIS accepts no
liability for any direct or indirect damage or loss resulting from the
use of any attachments to this e-mail.

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Mehta, Jay
Sent: Wednesday, 22 November 2006 21:49
To: International OpenROAD Users
Subject: Re: [Openroad-users] BringtoFront issue on an OR frame

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/20061123/7e073435/attachment.html 