CHALLENGE: Find a Way to Activate a Window

[Pete]

There's a catch... Of course virtual, not manual and it has to work in Linux and MacOS.

Okay, so in Windows we can use a WinAPI trick to min/restore a Window, which will "Activate" the window. Activate means it is not just in focus, it is also ready to use. With QB64, we can do a _SCREENCLICK to virtually activate it, just as if we clicked it! Oops, problem here is _SCREENCLICK, and other keywords like _SCREENPRINT, etc., are not supported in LInux and MacOC.

So the challenge is to replace the _SCREENCLICK line with something else (number of lines doesn't matter) that will have the same effect to activate the window.

So to try, you need to...

1) Copy and run the first and then the second snippet, in that order. They'll use the CLIPBOARD to message between the two windows. 

2) Adjust the windows on your desktop so they don't overlap.

3) Click the first program window to initially activate it.

4) Input a test message (Type and press Enter).

5) Notice the second window "Self-Activates" and displays the message received.

6) Input a reply.

7) The first window self-activates, displays the reply, and you are ready to input another message. It's like a ping-pong effect!

So the challenge is to sub out _SCREENCLICK with any line of code or sub-routine that will work in Linux / Mac OS to do the same effect, "activate" the window so we don't have to click on it.

This challenge is based on a much more polished chat app / messenger in this thread: https://qb64phoenix.com/forum/showthread...n=lastpost

If you solve it, you be the hero of the Linux/Mac community, literally billions upon billions of brain cells will thank you.

Program one, the host...

Code: (Select All)

WIDTH 50, 25
DO
    _CLIPBOARD$ = ""
    LINE INPUT "Message: "; msg$: PRINT
    _CLIPBOARD$ = msg$: msg$ = ""
    _DELAY 2
    DO
        _LIMIT 5
    LOOP UNTIL LEN(_CLIPBOARD$)
    '----------------------------------------------------------------------------------------------------
    ' Challenge: Replace line below with something that Linux/Mac can use to activate the window."
    _SCREENCLICK _SCREENX + 60, _SCREENY + 10
    '----------------------------------------------------------------------------------------------------
    msg$ = _CLIPBOARD$
    PRINT "Reply: "; msg$: PRINT
    _DELAY 1
LOOP

Program 2, the client...

Code: (Select All)

WIDTH 50, 25
DO
    DO
        _LIMIT 5
    LOOP UNTIL LEN(_CLIPBOARD$)
    '----------------------------------------------------------------------------------------------------
    ' Challenge: Replace line below with something that Linux/Mac can use to activate the window."
    _SCREENCLICK _SCREENX + 60, _SCREENY + 10
    '----------------------------------------------------------------------------------------------------
    msg$ = _CLIPBOARD$
    PRINT "Reply: "; msg$: PRINT
    _CLIPBOARD$ = ""
    LINE INPUT "Message: "; msg$
    _CLIPBOARD$ = msg$
    _DELAY 2
    _CLIPBOARD$ = "": msg$ = ""
LOOP

[SpriggsySpriggs]

I'm too lazy. Here. http://www.linuxfocus.org/English/March1...cle29.html

[Pete]

I'll pass on that rabbit hole. Look up "active window" for Windows and all you get is ways to focus it. That might be true for Linux / Mac, too.

If there is any QB/QB64 trick, that would be great, but off the top of my head, I can't think of one that works. For example: (_SCREENHIDE / _SCREENSHOW are not listed as non-x-platform, but they won't activate a window either.)

Now if QB64 would allow whatever Linux/Mac needs to get the window handle, maybe the min/restore trick would work.

Minimizing a window

xdotool:

xdotool windowminimize <window_id>

Un- minimizing a window

wmctrl:

effectively un- minimizing is done by:

wmctrl -ia <window_id>

I just have zero exposure to these OS so this is just me poking around at possibilities. Whatever support those command functions would need to communicate to the OS is beyond me.

Pete

[Pete]

Well no luck with RUN and a line number. That won't nmake it active, either. Now SHELL will make active the opening app, but I'd say reliability would be out the window with repeated shell and system calls, any we'd need a file system to inform the new app what to print back to the screen and where in the code to go. PITA even if by some Christmas miracle you could get it to reliably function.

_FULLSCREEN with _FULLSCREEN _OFF won't stop the previous app window from being displayed in front of the full screen app. Oh, and of course _SCREENICON won't un-minimize just because we pop a _FULLSCREEN command after it.

Well on to other things. I'll check back later to see if someone found a trick or routine I don't think of.

Pete

[mnrvovrfc]

The "wmctrl" might work only for XFCE. Right now I'm on EndeavourOS with that D.E. and had to install "wmctrl", so not everybody will have it on their Linux system. The good news is that it works but the commands are very specific. Basically give the window a title that could be easily captured and told apart from any other window. Then a few things could be done like:

Code: (Select All)

Force-close:
wmctrl -F -c weakwack

Minimize:
wmctrl -F -c weakwack -b add,hidden

Restore:
wmctrl -F -c weakwack -b remove,hidden

In these examples, "weakwack" (without double-quotation marks) is the title of the window. The "-ia" or anything involving "-i" just didn't work for me, the stupid program doesn't read hexadecimal numbers properly.

https://en.wikipedia.org/wiki/Wmctrl

Sadly otherwise it seems that only window managers are supported. If it exists it would have to be found eg. for KDE Plasma. The "compiz" is in some installations with MATE, especially Fedora. "OpenBox" is a window manager which looks very much like XFCE but was clunky for me to work with. Some distros have it like Porteus and Slackel (both based on Slackware).

EDIT: It might matter if the user enables composition or not for XFCE or for "compiz". I have it disabled on my installtion of EndeavourOS but it worked nevertheless. I would have to switch to my other computer with Fedora 37 MATE to test the other one.

https://linux.die.net/man/1/wmctrl

The following also needs to be installed and there's no guarantee for which D.E. it could work on:

https://github.com/jordansissel/xdotool

[mnrvovrfc]

Where are the Macintosh users? Get on over here and help us test stuff with QB64PE.

[Pete]

Fell comes to mind when MacOS is mentioned. I'd love to see him come back someday. I can't imagine going cold turkey on QB64, so hopefully he still codes with it.

I fiddled around a bit with TCP/IP networking today, but  even with "host" replacing "localhost" I could not get the two computers talking to one anther.

I had my office suite set up for networking, but that was through shared folders, not TCP/IP connections. Definitely two different beasts. I'm done working on this for now, but if I had more time to fiddle with it, I'd go back in time 20 years and see how I setup network sharing for my office suite, and try running the messengers in shared folders on two computers. That might work for home network connections. To communicate with an outside network seems like it would take a lot more protocol than what is presented here.

Pete

[SMcNeill]

A lot of the problem with TCP/IP communications is your system protecting you from yourself.  Is your firewall allowing the programs to communicate back and fort?  Are the router ports opened for two-way traffic?  Is your anti-virus detection being stupidly obnoxious and preventing one from executing properly?  Is your UAC protections too severe to allow the connections?

99.99999987% of the time the issue is one of those things interfering with execution, and they're issues that are almost impossible to diagnose or fix via something like forum help.

My advice:  Disable EVERYTHING you can while trying to get it going.  Turn off any damn windows security feature you can find.  (Just don't forget to re-enable when you're done.)  

If that doesn't work, my next guess is in your router itself.  You need to set up port forwarding, or open a port on the router to allow two-way communications.

If THAT doesn't work, ask yourself: "Are my machines REALLY on the same network??"  My main PC is hardwired directly into my main router.  My laptop runs off a wifi router -- which is plugged into my main router.  IT'S SUBROUTED and **NOT** a local connection to my PC.  Hell, even my iPad and my laptop are on *two different* networks -- even though they're both on the same wireless router -- because one runs on 2.3GHZ channels and the other on 6.0GHZ...

If the machines aren't on the *exact same* network, localhost isn't going to work.  You'll need their IP address, a dedicated port opened and forwarded for them to communicate across, and you'll need to make certain to use that port in your code.

TCP/IP is a wee bit more complicated than just writing to a shared network drive.  Hackers and viruses have pushed the technology to the point where it protects  us from so much, it protects us from ourselves -- even when we don't want it too!!

[Pete]

Hey Steve, in 1990 something I had a chance to buy a book, exclusively on TCP/IP protocols and programming. I passed. It was too big to fit in my car! Seriously, the damn thing was about 500 pages.

[Pete]

Oh, I should have put this in my last post, funny story...

When I was clearing all the firewall crap and telling my antivirus to Yogi off, one of those two little bleepers got into my system and disabled my ability to open a QB64 IDE window. That would freak some people out, but not me. I know it's personal. I yelled at the system... Don't make me put my boot up your ASCII!  I pressed the power off button and simply repressed it to start it back up. It muttered for about 3 minutes, but loaded Windows and worked just fine after that. New name: TCP/IP/PITA

Pete