Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

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.Clear
 DoEvents

retry:

 a=Clipboard.GetText
 DoEvents
 Sleep(500)
 If a=" Then GoTo retry
 Unload Me

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

The Sprezzatura Group

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…

The Sprezzatura Group

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

The Sprezzatura Group

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"

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/e7d6046d0f313c1a85256adf00345bc6.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1