[Openroad-users] FW: BringtoFront issue on an OR frame

[CAMF Delaunay]

BringtoFront issue on an OR frameHi all,

Regarding "The CurFrame.WidgetID is set after the frame is displayed so we 
send the external event outside of the initialize block."
I seem to remember that the CurFrame.window.realize method called from the 
Initialize block enforces OR to display the window of the the frame with, I 
guess, all the attributes ( not sure it is documented... )

Regards
Christian


----- Original Message ----- 
From: Eric Mischke
To: 'International OpenROAD Users'
Sent: Thursday, November 23, 2006 1:36 AM
Subject: [Openroad-users] FW: BringtoFront issue on an OR frame







From: Pat Weinman [mailto:pat.weinman at pateric.com]
Sent: Wednesday, November 22, 2006 4:34 PM
To: 'Eric Mischke'
Subject: FW: [Openroad-users] BringtoFront issue on an OR frame


Not sure if this made it to the mailing list.  Please forward...




From: Pat Weinman [mailto:pat.weinman at pateric.com]
Sent: Wednesday, November 22, 2006 4:21 PM
To: 'openroad-users-bounces at peerlessit.com'
Subject: RE: [Openroad-users] BringtoFront issue on an OR frame


Hi Jay,

We were experiencing a similar problem between two OpenROAD applications on 
the Windows platform (works okay on Unix clients with a simple 
BringToFront).  It took a while and with support from Ingres Corp we just 
came up with a solution today.

What was happening...the sending OR application would issue an external 
event to the receiving OR application.  The receiving application would then 
try the BringToFront method which didn't work.

To fix the problem we used a combination of external events and Win32 calls 
(user32.dll) .  When the receiving application is started it sends an 
external event to the sending application with the CurFrame.WidgetID 
information.  The CurFrame.WidgetID is set after the frame is displayed so 
we send the external event outside of the initialize block.

Since the Sending application now knows the WidgetID of the receiving 
application it can set the receiving application to the Foreground window 
using the windows api 'SetForegroundWindow (&hwd)' where &hwd is the 
receiving application's Curframe.WidgetID.  One important thing to note is 
that when the SetForegroundWindow is issued from the sending application it 
must be in the foreground.  Only the foreground process can set a new 
foreground process.  An excerpt from the sending application is shown below:

In Sending application create two 3gl Procedure components with Return Value 
'none'.  These appear to be case sensitive.
ShowWindow   < This is needed if the receiving application is iconified.
SetForegroundWindow  < This brings window to front.

Link 3gl components to c:\windows\system32\user32.dll by using the 'Browse' 
button or setting II_LIBU3GL to include c:\windows\system32\user32.dll.

In the sending application issue the following two lines before sending the 
external event to the receiving application:
CALLPROC ShowWindow(xxx, 1);
CALLPROC SetForegroundWindow(xxx)

where xxx is the CurFrame.WidgetID of the sending application.

This should bring the receiving application frame to the foreground.

 -Pat




From: openroad-users-bounces at peerlessit.com 
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Mehta, Jay
Sent: Tuesday, November 21, 2006 7:26 AM
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.
_______________________________________________________



__________ Information NOD32 1882 (20061124) __________

Ce message a ete verifie par NOD32 Antivirus System.
http://www.nod32.com




_______________________________________________
Openroad-users mailing list  Openroad-users at peerlessit.com

To unsubscribe please click on this link
mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

To subscribe please click on this link
mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe

__________ Information NOD32 1882 (20061124) __________

Ce message a ete verifie par NOD32 Antivirus System.
http://www.nod32.com