Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Laurence Pithie

Pages: [1] 2 3 4
Programming / Re: MeShell problem - start progname inherits stdin/out
« on: July 01, 2020, 04:25:25 pm »
fails because textfile.txt resides in the current directory an not in C:\. Any idea?
Before you issue the start command call  DosQueryPathInfo on the filename, passing FIL_QUERYFULLNAME as the second parameter. The fully qualified path name to the file will be in the buffer you pass as the third parameter You can get the buffer size for the returned full path name from DosQuerySysInfo using the QSV_MAX_PATH_LENGTH as the iStart and iLast parameter.

You'll need to parse the command line to ignore command line parameters and arguments to command line parameters, and deal with cases where more than one filename is passed on the command line.

Programming / Re: MeShell problem - start progname inherits stdin/out
« on: July 01, 2020, 11:16:44 am »
A program launched using the START command inherits the open file handles of the parent session. The /I parameter to the START command causes the new session to inherit the environment defined by the SET commands in config.sys instead of the CMD.EXE environment of the current session, in which case stdin will point to the keyboard and stdout will point to the monitor and won't be redirected to the pipe.

Utilities / Re: MeShell commandline frontend timetable
« on: May 22, 2020, 08:24:48 pm »
Code: [Select]
[C:\] zip<RETURN>
  adding: -

zip error: Interrupted (aborting)
(wild binary characters)
When I try to  compress stdin in version 0.63 of MeShell the EOF doesn't seem to reach the zip process, so I have to use ctrl-c to interrupt the process. Is that the behaviour you are seeing?

 AFAIR you are using a named pipe to communicate between the parent process and the cmdhelper process. So, if you write an EOF to the named pipe from the parent, reading the EOF in the cmdhelper process is interpreted as  there's no data in the pipe, so it doesn't write anything to the standard input of the zip process.
Code: [Select]
[C:\]cat <RETURN>
Shows the same behaviour, Typing the EOF character (ctrl-z) doesn't end the CAT process, it's ignored. The simplest work around  is probably to use a semaphore to indicate to the cmdheloer process that it should write an EOF to the standard input of the command running in the shell when the user types ctrl-z in the parent application.

Programming / Re: MeShell and PAUSE in a cmd file
« on: April 17, 2020, 02:40:35 pm »
Stdout is read by the child program and piped to the editor. You check for a prompt in the child program.
Parent pipes command to child program
child program checks cursor position
child program writes command to stdout
child program checks for output on stdout
    if there is no output on stodut
           check cursor position
           compare cursor position with original position

Programming / Re: MeShell and PAUSE in a cmd file
« on: April 17, 2020, 01:51:10 pm »
But I do not receive redirected stdout in the described case
You need to check for the change in the cursor position in the child/helper application, then use VioReadCharStr to get the prompt text and send that text through the pipe to the main application.

Programming / Re: MeShell and PAUSE in a cmd file
« on: April 17, 2020, 12:34:31 pm »
The standard i/o functions move the Vio cursor. I've attached a simple program, with source, to demonstrate.

Programming / Re: MeShell and PAUSE in a cmd file
« on: April 16, 2020, 04:18:50 pm »
While there's no output to stdout until the eol is recieved the cursor position will have changed. Calling VioGetCurPos before issuing a command, check for output on stdout, and if there is no output call VioGetCurPos again and compare the two values. If the values differ then use VioReadCharStr with the two values you have for the cursor position to get the output prompt and display it to the user. It's similar to the logic you used for capturing Vio Output.

Programming / Re: how to stay a window on top
« on: April 04, 2020, 12:51:15 am »
One option would be to place the Main window behind the client window using WiinSetWindowPos when the client program is active. One way to  achieve that is by placing a check for the clinet program being active and calling WinSetWindowPos at the end of processing the WM_PAINT message in the main window procedure. Essentially what you woulld be doing is swapping the Z order of the two windows if the user brings the main window to the front while the client program is active.

Programming / Re: how to stay a window on top
« on: April 03, 2020, 09:32:13 am »
The FCF_SYSMODAL creation flag creates a system modal window. You can also use the WinSetSysModalWindow call to change a window into being the system modal window or from being the system modal window.

Programming / Re: Manipulating a PM window from another program
« on: March 29, 2020, 03:40:13 pm »
Pass the window handle of the Vio window as the first parameter of the WinSubClassWindow call with a pointer to the custom window procedure as the second parameter. Pass any messages that you don't explicitly process to the original window procedure (which is the return value from the WinSubClassWindow call) in a similar fashion to the way you pass messages you don't process to the standard window procedure in window classes you create in your own code. Because you can only subclass windows started in the same session you need ti issue this call from the helper app. There's a discussion on calling PM from AVIO here.

Programming / Re: Manipulating a PM window from another program
« on: March 29, 2020, 09:25:21 am »
One solution would be to  subclass the frame window and process WM_CLOSE and WM_QUIT messages in the custom window procedure.

Programming / Re: Shared Memory correct usage
« on: March 21, 2020, 01:51:46 pm »
As a suggestion, for avoiding pitfalls such as you describe in future, you should abstract your shared memory usage and wrap it in an api.

Programming / Re: Observing if a program uses vio calls
« on: March 09, 2020, 12:02:25 am »
There are a host of pagers, including variants which pop up PM windows. Another common scenario is piping text through troff into a postscript viewer.  It's not just Vio programs, most *nix derived utilities if you don't supply a filename will read from stdin by default, and in that scenario if you forget to provide a filename you will not get a prompt returned from the helper program to indicate in the PM program that it's waiting for input.

Programming / Re: Observing if a program uses vio calls
« on: March 08, 2020, 03:51:02 pm »
Can I perhaps send a message to the helper (the way I have already programmed via Semaphores and Shared Memory) that a user has pressed a key on the keyboard and the helper program writes the character to the keyboard buffer of its own session?
What you did in that instance was use the semaphore to trigger sending a signal to the helper precisely because the helper didn't have access to the keyboard to get the break signal triggered by pressing ctrl-c on the keyboard. Writing to the screen isn't a keypress, the process running in your shell is waiting for a keypress, Vio programs use KbdCharIn, KbdStringIn or KbdPeek to read key presses and they only have access to the keyboard when they're in focus. For a non PM session you can use a character device monitor to insert data into the character stream from the keyboard.
Thinking about my problem has resolved that if no VIO output happened and the user presses SPACE (SPACE is no useful answer for a menu or Y/N query), it is most likely, that the SPACE has to be sent to the VIO window and not to STDIN. This should cover the majority of cases.

It's not the Vio Window that's waiting for input, it's the process that's running in the shell that's running in the client area of the Vio Frame Window that's waiting for a key press. Even if you subclassed the client window to process a message, that's still not going to send a keypress to the process running in the shell that's running in the client window, because that process will be using KbdXXXXXX functions to read a physical key press, it knows nothing about messages.

What might work is to switch focus to the Vio Frame Window before showing the prompt in the editor window using WinSetFocus, that way the Vio Window gets the keypress and not the editor window. However, if that works at all, it's incredibly fragile, a simple alt-tab by the user breaks it.

I still can't see a use case for this feature in a text editor. I can see the user wanting to be able to transform text using complex pipelines and batch processing, but why would they be processing text through either another full screen interactive text editor or a pager as part of that process? The output is going to be appearing in the text editor, so I don't need a paginator when I can scroll backwards and forwards through the output text and I'm in a full screen interactive text editor, why would I want to run another one as a subprocess? It seems to be a misfeature that nobody would use except by accident, and that's what the interrupt or break signals  are for.

Programming / Re: Observing if a program uses vio calls
« on: March 08, 2020, 12:38:10 am »
The problem with sending a WM_CHAR, or indeed any sort of message is that the cmd process doesn't have a message queue. The frame window does, but that's handling messages for the frame window, the system menu etc.

I have to say that, given the purpose is to get the output of a command into the text editor, I can't see a use case that requires it to be piped through a paginator in the cmd shell. There's no relationship between the dimensions of the cmd shell and the text editor, so it'll end up looking odd,  and, presumaby, the user wants to do some editing of the output text in which case piping the output through a paginator is pointless.

There are a number of implementations of the MORE command, it's one of the GNU utilities, along with LESS, so getting access to source code isn't a problem. LESS is part of the coreutils available via ANPM, and is a far better pager.

An alternative approach would be to deal with piping the output from one command into another within the editor. Instead of passing a line of commands containing pipes to the shell parse the command line and pass each command seperately, collecting the output of each command and using that as the input for the next command in the pipeline. That lets you do your own paginationin the editor, where it makes more sense.

Pages: [1] 2 3 4