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

[Mehta, Jay]

Pat,
 
Your response has definitely shed more light on the issue and the reason
why these APIs are not working as expected. I'll attempt to incorporate
your suggestions - unfortunately, it requires the involvement of another
team and may not be as quick as I'd hoped. But a big help nevertheless.
 
Thanks,
Jay

-----Original Message-----
From: Eric Mischke [mailto:eric.mischke at pateric.com] 
Sent: 23 November 2006 00:36
To: 'International OpenROAD Users'
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.

_______________________________________________________

 

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