[Openroad-users] BringtoFront issue on an OR frame

Colin Hay Colin.Hay at ing.com.au
Wed Nov 22 17:29:38 EST 2006


You must have II_DATE_FORMAT set to MULTINATIONAL ?
 
set it to anything e.g. GERMAN
 
to default dates to CCYY format
 

Colin Hay

Database Administrator

ING - Felix project

 

Lvl 5 Pitt St

w: +61 (02) 8238 3669

m: 0415 526 343

e: colin.hay at ing.com.au

 

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Piero
Sorgini
Sent: Wednesday, 22 November 2006 4:59 PM
To: International OpenROAD Users
Subject: Re: [Openroad-users] BringtoFront issue on an OR frame


Hi All.
 
I am trying to copy a flat file using the copy command although the date
fields needs to be copied in as a date
cause dates prior to yr 2000 are not taking into consideration of the
II_DATE_CENTURY_BOUNDRY.
The flat text file is tab delimited. 
 
Would appreciate if someone could advise if this can be done.
 
Cheers.
 
Piero.

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Collins,
William - ES/EW
Sent: Wednesday, 22 November 2006 9:18 AM
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: 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
	
	
*************************************

This e-mail has been received by the Revenue Internet e-mail service.

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

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



IMPORTANT NOTICE
This communication including any file attachments is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, or the person responsible for delivering this communication to the intended recipient, please immediately notify the sender by e-mail and delete the original transmission and its contents. Any unauthorised use, dissemination, forwarding, printing, or copying of this communication including any file attachments is prohibited.

It is your responsibility to scan this communication including any file attachment for viruses and other defects. To the extent permitted by law, ING and its associates will not be liable for any loss or damage arising in any way from this communication including file attachments.

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


More information about the Openroad-users mailing list