O7: Disable the OMNIS7 Close Box in WIndows

Fred Brinkman fred.brinkman at euromnis.org
Thu Apr 9 06:47:18 EDT 2009


I'm no Windows person, so sorry, can't help you there...

I would assume #11009 is only trapped when Omnis does not quit 'the  
regular way' so I'd assume it would be possible for you to trap that  
circumstance. But maybe I do not understand what you're exactly trying  
to do.

Fred


Fred Brinkman
http://www.euromnis.org

**********************************************
Fred Brinkman Consultancy
B-1000 Brussels

Tel. +32-474-83 80 80
Fax +32-2-330 10 31 (on request)
mailto:fred.brinkman at euromnis.org
*********************************************








Op 9 apr 2009, om 12:19 heeft Stephen Miller het volgende geschreven:

> Thanks Fred.
>
> Yes you are right it works flawlessly but my problem is you use the
> right number (#11009 ) But my real problem is I want to throw a  
> message
> if the user quits from inside the program and in some special
> circumstances I do not want to throw a message if the quit is send  
> from
> an external windows API message. My problem is I cannot necessarily
> predict at this stage of the development what program will instruct
> OMNIS to close. Therefore I am trying to create reasonably simple
> generic way of telling the difference.
>
> Not being a windows API guru I am a bit lost except to reduce the  
> issues
> by removing the close box in windows and treating everything else as  
> an
> external event.
>
> 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 Fred
> Brinkman
> Sent: Thursday, 9 April 2009 8:02 PM
> To: OmnisDev List - English
> Subject: Re: O7: Disable the OMNIS7 Close Box in WIndows
>
> Stephen,
>
> #11009 should do this (not #11109)
>
> f.i. in your library procedure
> if #11009
>   do this or that
> end if
>
> should work flawlessly whenever Omnis quits not via Quit Omnis
>
> Fred
>
>
> Fred Brinkman
> http://www.euromnis.org
>
> **********************************************
> Fred Brinkman Consultancy
> B-1000 Brussels
>
> Tel. +32-474-83 80 80
> Fax +32-2-330 10 31 (on request)
> mailto:fred.brinkman at euromnis.org
> *********************************************
>
>
>
>
>
>
>
>
> Op 9 apr 2009, om 11:54 heeft Stephen Miller het volgende geschreven:
>
>> 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
>> ______________________________________________________________________
>> _____________________________________________________________
>> 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
> ______________________________________________________________________
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com




More information about the omnisdev-en mailing list