Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Ideas for implementing pShell

by Jouke (Curate)
on Apr 03, 2004 at 06:53 UTC ( #342239=perlquestion: print w/replies, xml ) Need Help??

Jouke has asked for the wisdom of the Perl Monks concerning the following question:

Dear fellow Monks,

For people who don't know about the pVoice project I work on, a short description:

Using wxPerl I create applications for severely disabled people like my own daughter Krista. So far I created pVoice (which gives people a synthetic voice by selecting symbols and letters to create sentences), pStory (listening to and viewing pages of books) and pType (to support writing by selecting letters only to create words or sentences).

More information on

The idea now is to create a shell from which the user can fire up the software, and which keeps track of running applications, that may be minimized and restored. Think of it as a mini-windowmanager within Windows (yes, it's Win32 only).
The userinterface isn't the problem. I've created a bunch of modules to handle the userinterface for these kinds of applications.

My question to all of you is how I could implement the windowmanagement itself. The shell should fire up complete (standalone) applications. The applications themselves are able to minimize or close themselves, whereas the shell should be able to restore the applications that are minimized, not firing up a second copy of the same application, and also know when an application has been closed.

What wxPerl functions can I use for these management-tasks, or -in case wxPerl doesn't provide the functions I need- what other Perl modules can I use?
I could of course start struggling myself, but maybe you know an easy way of doing this.

Jouke Visser, Perl 'Adept'
Using Perl to help the disabled: pVoice and pStory

Replies are listed 'Best First'.
Re: Ideas for implementing pShell
by tachyon (Chancellor) on Apr 03, 2004 at 08:20 UTC

    You will be doing it via Win32 API. Although it may seem rather unrelated at first have a look at Win32-Screenshot which provides a whole lot of window handling methods like: WindowFromPoint GetForegroundWindow GetDesktopWindow GetActiveWindow GetWindow FindWindow ShowWindow GetCursorPos SetCursorPos GetClientRect GetWindowRect BringWindowToTop GetWindowText IsVisible GetTopWindow Minimize Restore ScrollWindow. The XS part just calls the native Win32 API calls. As you can see the Perl wrapper code is very simple.



      Win32::GUITest might give you some ideas, too. I've only just started using it, but it has a lot of potential.
Re: Ideas for implementing pShell
by PodMaster (Abbot) on Apr 03, 2004 at 23:38 UTC
    I got tired of seing 20 cmd.exe windows in my taskbar, so I set out to steal them. This is my proof of concept (what you want to focus on is Win32:: and EVT_ calls ) While experimenting with this I wanted a way to map processes to top level windows, this is about as good as it gets

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      Great! This is useable code for this project! PodMaster++

      Jouke Visser, Perl 'Adept'
      Using Perl to help the disabled: pVoice and pStory
        Another thing I've just discovered is that you cannot wrap
        Win32::API::->Import( "user32", "DWORD GetWindowThreadProcessId( HWND hWnd, LPDWORD lpdwPr +ocessId)" ) or die $^E;
        in a begin block. If you do, it won't work properly. For example if you tried GetWindowThreadProcessId($handle, $procid); $procid would not be populated with the process id as is expected. This drove me crazy 10min ago.

        update: also, be sure the new parent window has wxCLIP_CHILDREN on, otherwise flicker galore

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

Re: Ideas for implementing pShell
by elwarren (Curate) on Apr 04, 2004 at 16:08 UTC
    A good way to do this would be to borrow a page from unix add some simple lockfile methods to your code. Choose a common directory for your programs, maybe "c:\pvoice\lock\" When you launch a program it should create a file and possibly put it's process id inside. When the program exits, remove the file. When programs startup they should check for their respective lockfile and exit if its found. Need to kill or stop a process, open it's lockfile and use it's pid. If a process crashes then the lockfile will exist but the process id will not, the crash can be recorded and a new instance fired up.

    This could be implemented in each of your programs without a requirment of the minimanager. This is how many unix programs manage use of the serial ports without having complex interprocess communications.

    I'm sure there's some sort of module out there to do this already. Searches for either lockfile or process management on cpan should turn something up.

Re: Ideas for implementing pShell
by aquarium (Curate) on Apr 04, 2004 at 08:18 UTC
    this is not related to your question, but i thought if you haven't come across this software then you might like to check it out. it's called "dasher", and disabled people can use mouse or mouth joystick etc. to type at a pretty good rate. good luck with your software.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://342239]
Approved by davido
Front-paged by jeffa
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2019-07-23 01:00 GMT
Find Nodes?
    Voting Booth?
    If you were the first to set foot on the Moon, what would be your epigram?

    Results (22 votes). Check out past polls.