O7: Disable the OMNIS7 Close Box in WIndows

Stephen Miller Stephen.Miller at isofthealth.com
Thu Apr 9 05:54:26 EDT 2009


Hi all

I have an interesting problem in OMNIS7.

Let us assume someone clicks on the external wrapper layer and clicks on
the [X] close box. 

I need to trap a difference between a user selecting the File Menu Exit
option from my program ( which is easy enough - I can just set a Library
variable) to distinguish between OMNIS7.exe receiving an internal
instruction to quit or an external instruction, for example the
equivalent of choosing OMNIS7.exe from the task manager in Windows.

So I can trap for the #ER=11109 value in my library control procedure
and if my internal Quit event is received I can do something and if this
value is not set then I can do something else.

The problem is that the user may also choose the close box for OMNIS7.

In this instance I cannot trap for this event, clicking the external
close event, ( am I right about this?) and so I need to setup my OMNIS
environment on startup so that the Close box [x] is not available or
disabled.

This code snippet would seem to be the correct one:

"Private Declare Function GetWindowLong Lib "user32" Alias
"GetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long) As Long
Private Declare Function SetWindowLong Lib "user32" Alias
"SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long, ByVal
dwNewLong As Long) As Long
Private Declare Function SendMessage Lib "user32" Alias "SendMessageA"
(ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As
Any) As Long
Const GWL_STYLE = -16
Const WS_SYSMENU = &H80000
Const WM_NCPAINT = &H85
Private Sub Command1_Click()
SetWindowLong hwnd, GWL_STYLE, GetWindowLong(hwnd, GWL_STYLE) Xor
WS_SYSMENU
SendMessage hwnd, WM_NCPAINT, 0, ByVal 0& 'repaint the title bar
End Sub"

My problem is the above... it doesn't seem to make a lot of sense to me.
The simple calls I can do but this one maybe should be wrapped in a Dll?

Any one like to have a crack at this or know how to do this direct with
Register and Calldll?

Any other ideas?

Regards

Stephen Miller 	
Business Analyst 	
iSOFT - An IBA Health Group Company 	
Darling Park, Tower Two,
Level 26, 201 Sussex Street,
Sydney NSW 2000 Australia 	
Tel: +61 (0) 2 81156302	
Fax: +61 (0) 2 8251 6801 	
Email: stephen.miller at isofthealth.com 	
Web: http://www.isofthealth.com/ 	
 	
IBA Health Group Limited is a company registered in Australia (ABN 66
063 539 702). This email and any attachments are confidential, subject
to contract and copyright, and may be privileged. If you have received
this email in error, please notify the sender immediately, delete it and
destroy all copies. Any views expressed are those of the individual
sender unless expressly stated otherwise. In respect of this email and
any attachments, to the extent permitted by law, no warranty is given
and all liability is excluded including, without limitation, liability
for any loss or damage caused by way of computer virus, defect, delay,
or interruption.	
-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com
[mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Michael
Houlberg
Sent: Thursday, 9 April 2009 10:14 AM
To: OmnisDev List - English
Subject: Re: O$: is this a text file import bug?

Alan,

Yes, this is a new bug in 4.3.  Tech support tells me it is fixed the  
in 5.0 version.  I ended up having to write a routine to parse out  
double quote characters, except where they are the first and last  
character between tabs.  Yuck!

However, another solution if you don't have to do this often, open the  
file in Excel, then save again as tab delimited.  It puts extra  
delimiters around the offending columns and Omnis then can read it OK.

Michael Houlberg
Houlberg Development, LLC

On Apr 8, 2009, at 4:42 PM, Alan Schmidt wrote:

> I'm trying to import (using the Import Data command) a tab delimited  
> text
> file with numerous columns. One of the columns contains long text  
> entries
> some having a double quote character (for inch measurements, and  
> there's no
> more than one double quote per record). When this file is imported  
> using
> Studio 4.3.1, the double quote character causes the tab delimiters  
> for all
> the following columns to be ignored and they are all crammed  
> together into a
> single field. If I remove the double quote using a text editor it  
> imports
> fine. I can also import this same file properly using Studio 4.2  
> with or
> without the double quotes. Is this a bug in Studio 4.3 or is there a  
> new
> preference setting that changes the import behavior?
>
> Thanks for the help.
>
> -Alan
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com

_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



More information about the omnisdev-en mailing list