Closing non-OI application (OpenInsight Specific)
At 08 OCT 2001 05:31:53AM Colin Rule wrote:
From my OI app I launch a small VB application to communicate to the COMM ports.
When my OI form closes, I want to close the VB application too.
I am using UTILITY RUNWIN for the launch, and can get the instance handle etc from this.
I was initially making the VB app loop until a given DOS file was present and then closing from the VB app, but this put too much of a load on the loop, as there are other events in the VB app too.
Any ideas how I can kill the VB app from OI?
Thanks
Colin
At 08 OCT 2001 10:02AM Simon Wilmot wrote:
If you can get the Window handle, presumable from the FindWindow api function,
Add the function SendMessage (if you have FindWindow, it may already exist) as
LONG PASCAL SendMessage(USHORT,USHORT,USHORT,LONG)
And then you can use that as a subroutine, passing it 16 (destroy) ie
SendMessage(handle,16,0,0)
Best of luck,
Simon
RebusHR
At 09 OCT 2001 05:05AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Here are some other options for you to consider…
In your VB general declarations, try:-
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Then inside your loop you could add the following VB code
(varying the number to adjust the trade-off between CPU
activity and poll interval)
Sleep (500)
Another option would be to clear the clipboard from VB
first of all, then trigger a VB application shutdown
by sending data from OI to the clipboard. Then after
your comms session loop until instructed by OI to unload.
Clipboard.ClearDoEventsretry:
a=Clipboard.GetTextDoEventsSleep(500)If a=" Then GoTo retryUnload MeThen to shut down VB simply add data to the clipboard from OI.
In OI, using the set_property routine, place string data into
the TEXT property of the CLIPBOARD object.
World Leaders in all things RevSoft
At 09 OCT 2001 10:08AM Matt Sorrell wrote:
Nice little piece of code, but I would make one stylistic/structural change.
GOTOs are generally considered _bad_, but I don't wish to start a holy war. I would rewrite it as thus:
Clipboard.Clear
DoEvents
a=Clipboard.GetText
Do While a="
DoEvents
Sleep(500)
a=Clipboard.GetText
Loop
Unload Me
As I said, it's more stylistic than anything.
*duck*
*run*
*don flame-retardant suit*
msorrel@greyhound.com
At 09 OCT 2001 10:38AM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
You can tell when one of our members has been immersed in Assembler for a while on current projects. In Assembler, no one can hear you loop…
BNE and out…
World Leaders in all things RevSoft
At 09 OCT 2001 11:01AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Matt -
You're correct - goto's are bad stylistically. The call to SLEEP(500) was the essential code here. I often get told to
go and JMP (in the nicest possible way) .
World Leaders in all things RevSoft
At 10 OCT 2001 05:18AM Colin Rule wrote:
Simon,
Thanks for this.
I downloaded HandleSpy, to find the handle, created the API call and hey presto, it closed.
Brilliant stuff.
Colin
At 10 OCT 2001 10:34AM Aaron Kaplan wrote:
I'll post with my name, since The Collective has spoken.
GOTOs have a place and use, though it's use should be cautious. Let's not forget that all loops in R/BASIC compile down to If…Then..GoTos…
The reason for avoiding GOTOs is the prevention of spaghetti code. Jumping all over the place will usually cause problems in understanding the code. Purists, taking a good idea too far, mandated the elimination of this in higher level languages, always stating there is a clearer way to do this.
However, small tight loops can best be controlled with GOTOs, especially loops without ends, for instance, the INPUT.CHAR loop. Though a simple Loop/Repeat would work the same.
In answer to this, when 3.12 was shipped, I added in a JUMP command since we all know GOTO is forbidden, but JUMP from ASM is acceptable.
Aaron
At 10 OCT 2001 10:15PM Scott, LMS wrote:
Hi Aaron
You make the Collective seem like the Borg but it reads more like "Our esteemed leader who doesn't like to admit to leading".
I wish GOTOs weren't such a bug bear (or is that "bug maker"). Although they are much more easily used to write spagetti than anything else. I find that writing them out involves vast quantities of "tramp" data or flags, ie having something called "error" which has to be checked before any processing is done, instead of just "GOTO"ing an exit.
Except if I write a Goto a SKIP_RECORD or EXIT_PROGRAM I have to put in a
GOTO EXIT_PROGRAM ;*————————————————-]
so I see it instead of tuning it out. I tend to favour the tramping error flag.
The worst coders I have encountered could write incomprehensible code without using a single goto. Or a subroutine either. Or a variable with more than two characters in its name. Or any indentation. Or block code. Of course they used comments. I think the comments must have been written in Polish though. I'd had half a chance if it was reverse-Polish.
example:
* these are positions of record/row being written for file
equ false to 0
equ true to 1
I guess they're positions on a debate team?
Scott, LMS
I'd rather be S 26'28.012" E 132'03.379"