Want to use qb64 as a gui interface, need a way to know _dontwait shell finishes

[doppler]

A GUI I use is almost worthless.  I want to replace it of my own making using QB64. Unfortunately to make it multi-process I need to use _dontwait with shell command.
Here is the rub, if I use just shell I would know when the shelled process ends.  But the task would be single threaded.  If I use the _dontwait with shell I have no way to know when the task completes (or even hang/timesout).  So is there a way to get the task process ID to monitor the tasks ?

I can only think of using lock/process files to monitor.  While the shell process's delete the locks upon completion.  Then I can start a new shell.

Am I barking up the wrong tree?  I have looked for a generic GUI, where I can add the process details my self.  No luck finding one.  Everyone I have found is "Using python to create your own GUI" or using java.  I don't have the inclination to start learning yet another language.

[Pete]

It has been awhile, but I've done this in the past. You can try working with locks, I did that with networking so a file being written to couldn't be accessed by another party until the write process was completed.

As for SHELL, I think I did this: Write a second QB64 program that has the SHELL, without _dontwait in it and have it run minimized or hidden. Call SHELL _dontwait to that QB64 program. Monitor that program in your main program loop, to see when it is closed. A simple way to do that is to have the main program make a temporary file, just before it shells to the second Qb64 (Shell operations) program, and have the second program kill that file, after it completes the shell, and before it closes and terminates with the SYSTEM command.

So something along the lines of...

Code: QB64: [Select]

1. 'Main Program...
2. ff = FREEFILE
3. OPEN "myfile.tmp" FOR OUTPUT AS #ff
4. _DELAY .1
5. SHELL _DONTWAIT "START /min secondqb64prog.exe"
6. ' PROGRAM LOOP
7. DO
8.     IF _FILEEXISTS("myfile.tmp") THEN ELSE flag = -1
9.     ' Other program stuff...
10.     IF flag THEN flag = 0: ' Do whatever you need with it, now that you know the SHELL process has completed.
11. LOOP
12.  
13. '----------------------------
14.  
15. 'Second QB64 Program
16. SHELL "whatever"
17. _DELAY .1
18. IF _FILEEXISTS("myfile.tmp") THEN KILL "myfile.tmp"
19. _DELAY .1
20. SYSTEM
21.  

I haven't revisited this for about 4 years, so I hope I recalled it correctly. I also remember there was some glitch I had to tweak, but I cannot recall what that glitch was. Anyway, it's simple enough to test You can also check into the QB64 _SCREENHIDE command, if you want to run that second program hidden, instead of or as well as minimized.

I may have also figured out another method, but I just can't recall it at this time. Also, someone else might post something that doesn't require a second dependent program be made. For instance, with Windows systems, I would think you could use an API library to get the handle of that SHELL procedure, and then directly monitor it until it no longer existed.

Pete

[doppler]

I have worked with locks, permissions and transaction process a lot in the pass.  Banking requires transactional process locks and committal sequences a lot.  If you look at the mode for "Open" command you will see a lot of that.

I was hoping for an easy way to monitor the process in windows thru the task monitor.  Much easier than creating my own lock/and/proceed process. 

[Pete]

@Windows API: Well maybe this will help get you started: https://www.qb64.org/forum/index.php?topic=1367.msg105566#msg105566

Pete

[SMcNeill]

Can you use _SHELLHIDE for this?  https://www.qb64.org/wiki/SHELLHIDE

It waits for a return value when the shelled process is finished, so it should do whatyou want.  (I think.)

[Pete]

_SHELLHIDE, how long has that one been around? It's what I would have used years ago, to let me know when a shell call, that goes over the internet and takes a while to return and terminate, is finished. I mean it was fun coding a way to that, back then, but this looks like it's just what the doppler ordered!

Pete

[SMcNeill]

It’s in SDL, if I’m not mistaken, so it’s been around for a day or 1324...

[Pete]

I really need to get _OUTMORE. I mean _SHELLHIDE

Oh well, it's still a lot of fun figuring out methods, but I'd be lying if I said I'd rather figure out methods for existing keywords. I may need to go through the QB64 underscore list someday, and see if there is anything else useful to this old SCREEN Zero Hero. I may even look through my files and see if I can update the routine I made to apparently emulate _SHELLHIDE. It's just so damn dusty in those darn QB archives!

Pete

[doppler]

The problem with shell and shellhide is they callout to execute and wait.  One does it like a ghost.  If I want to operate multi-threaded (the program in mind allows multiple instances), I can't use a normal shell call.  If I use the don't wait option of shell, I can't track when a shell process is done.  If I knew the PID, I can watch until the PID disappears and start another shell.  "Tasklist" is a nice command to inform about tasks and thier PID's.  I could shell to tasklist and capture the results.  I need a kernel32 call to know when the task completes, and time it myself to determine a hang.

I am not a windows interface expert.  I need a push to use the right stuff.  If kernel32 is doable it would be nice.  Otherwise I have to use lock and release files using another shell sub-process.  I promise to tidy it up and release it the program section.

The program will compress PNG graphic files.  It's call PINGO (program in mind ref: eariler), the GUI he wrote for PINGO is call PINGA.  It sucks.  PINGA may look good on the outside.  It's a turd on the inside.  Almost no real testing.  Any feedback is treated with disdain even if the feedback is positive improvement.  Being told I don't know what I am talking about and still looking for a donation is ass backwards.

[Pete]

Did you check the link I posted? https://www.qb64.org/forum/index.php?topic=1367.msg105566#msg105566

Pete

[doppler]

Did you check the link I posted? https://www.qb64.org/forum/index.php?topic=1367.msg105566#msg105566

Pete

Yes, I did.  The example you pointed out is for current PID.  So if I shell out to execute via another shell "PINGO".  I will still have no idea the PID of the shelled Pingo.  That's the one I need to monitor.  Tasklist will get me part of the way.  Or if there was a windows call to return the PID number based on the title window name.  I could make multiple copies of pingo ID differently.  And find the copy ID's PID's.  Even a do loop looking for the PID id's until it errors (pingo exits closing PID).  Could work.

So much pre-prep groundwork before I can start coding.  I don't want to start a half-cocked effort, only to find I made the wrong assumptions and start over.
Good night for now, see-ya in a bunch of hours.

[SMcNeill]

DECLARE DYNAMIC LIBRARY "user32"
  FUNCTION FindWindowA%& (BYVAL class AS _OFFSET, Title$)
END DECLARE

_TITLE "Windows Test"

'// Get the window handle (as a long)
hwnd%& = FindWindowA(0, "Windows Test" + CHR$(0))
PRINT "Handle:"; hwnd%&



Just use the title name of the window you’re looking for.

[doppler]

Steve,
We are almost there.  I looked up the function.  This very well could fit the need for the deed.
Unfortunately  handle is always coming up zero.  I tried and can't figure it out why.

Just so close now I can taste it......  This will when working become another nugget.

[Pete]

It comes up zero because you are not giving it enough time to poll the API and return a value. You need to stick some _DELAY .1 or longer in your code statements, around the API calls.

Pete

[doppler]

Thanks Pete, I am so ready to code now.

Again Steve for the win!