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 - Rich Walsh

Pages: [1] 2 3 ... 8
Applications / Re: XWP v1.0.13 GA
« on: May 23, 2020, 07:52:08 pm »
is it recommended unistalling the existing previous version before installing this last one?

Install the new version on top of the existing one. There is no need to uninstall anything.

Multimedia / Re: Use of webcam
« on: May 23, 2020, 12:35:56 pm »
When will (32-bit) ArcaOS Drivers support isochronous transfers ?

Isochronous transfers are fully supported for USB2 and have been for a while. I have no problems using Lars' USB Audio drivers with the AN stack.

I think someone's confusing the issue with USB3 where (IIUC) it is still under development.

Applications / Re: XWP v1.0.13 GA
« on: May 23, 2020, 10:17:04 am »
When I position the mouse cursor over a Program Object and click once the
Folder Status Bar shows the filename (slightly) incorrectly by inserting a space
between the last character of the .exe extension and the surrounding quotes.
Is this a known bug/design feature?

This is an artefact of the way XWP formats the string, replacing placeholder characters with actual data.

The formating string for program objects contains "$p $P" where $p is the exe name and $P are the parameters. Replacing $p, you get "program.exe $P". Replacing $P, you get _either_ "program.exe parameter" if there is a parameter _or_ "program.exe " if there isn't one.

IOW, that space you're seeing is simply the space between the $p and $P. I'll see if I can clean this up...

Programming / Re: A clock in WPS - Educational Project
« on: May 19, 2020, 07:16:30 pm »
Martin, add the following to your environment before compiling. They set default commandline options and directories:

(this last line assumes you also have a "SET TOOLKIT=<path>" in the environment)

When compiling, use:  "sc -r -S128000 -C128000 <file>"

One other thing... since this project isn't associated with XWP, it would be better to use a different prefix for its files and classes. Perhaps "MIClock" would be more appropriate (especially in Spanish).

Programming / Re: how to stay a window on top
« on: May 11, 2020, 03:15:01 pm »
I wonder why a Dialog Window has the behaviour I would like to have. Dialog Windows always stay on top above the main program (standard) window.

This is really sad. Hasn't anyone RTFM?

You're about to abuse a powerful - and possibly very annoying - feature (WS_TOPMOST) simply because neither you nor any of the other respondents knows one of the basics of PM programming: an owned window is always higher in the z-order than the frame window which owns it.

If a dialog is always on top of the window which created it, it's because the dialog is owned by that window. Change its owner to HWND_DESKTOP and the dialog will be free to go anywhere in the z-order. If you need a specific z-order for your windows, establish an ownership chain - don't use WS_TOPMOST.

BTW... there are times when WS_TOPMOST is called for. but it should always be at the user's discretion (i.e. he can turn it off).

Programming / Re: Manipulating a PM window from another program
« on: March 27, 2020, 05:26:01 pm »
Code: [Select]
hw = WinWindowFromID(VIOhandle, FID_SYSMENU);

Where is the failure?

SC_CLOSE appears on a submenu of FID_SYSMENU. Therefore, the correct call is

Code: [Select]
hw = WinWindowFromID(VIOhandle, FID_SYSMENU);

Programming / Re: Manipulating a PM window from another program
« on: February 18, 2020, 06:02:19 pm »
The correct way to do this:

* delete menuid SC_CLOSE from the System menu (FID_SYSMENU); this will also remove the Close button from the MinMax button (FID_MINMAX)

* delete menuids SC_MAXIMIZE and SC_RESTORE from both the System menu and the MinMax button
* delete menuids SC_MAXIMIZE and SC_RESTORE from the MinMax button, and SC_MAXIMIZE from the System menu

* do NOT remove the Minimize button. It is the user's right to clear his screen if desired - even if it may have negative consequences in some *few* situations.

Edit: leave "Restore" on the System menu for use when the window is minimized

Hardware / Re: Thinkpad X60s + X6 UltraBase
« on: January 31, 2020, 07:54:53 pm »
Also, be aware that once a drive has been ejected, it must be physically detached and reattached before it can be mounted again.
On my system it is not necessary physically detach and reattach drive to mount it again. 'USB widget Refresh' on XCenter usually do the job.
Rescan in FM/2 does the same thing.

If you have Lars' version of 'USBMSD.ADD' installed, a physical removal and reinsertion is not needed to remount a drive after it has been ejected. However, on Hakuchi's freshly-installed AOS system with the IBM driver, it definitely is.

Hardware / Re: Thinkpad X60s + X6 UltraBase
« on: January 30, 2020, 05:40:42 pm »
It doesn't work correctly when trying to access it via XCentre widget or by kliketi-klik in file manager (or what ever that is called in OS/2). It does show up when it is inserted when booting but it cannot be accessed. It shows up "Empty" in the XCentre as I explained earlier. I just did test your suggested remove/reinsert and it seems to not work at all. It's not seen anywhere. This is when one uses USB ports on the laptop itself.

When inserted into two ports on Ultrabase, it is recognised, but cannot be accessed. Shows up as "Empty" on XCentre. One can "Check disk" however and all seems to be ok. But there is a twist to this!

When I open up Text Editor and browser through there it is seen right and those files can be touched like a girls in the red-light district ... So something is fishy.

Open an OS/2 commandline session (an "OS/2 window") and enter "dir X:" (where x: is the letter assigned to this drive). If the WPS (the GUI) has been telling you that the drive is empty, then you should get a message saying "The disk or diskette can not be accessed". To fix this, run 'chkdsk' from the commandline (yes, I see you ran it from the GUI, but do it anyway):  "chkdsk X: /f"  When done, try doing a "dir" - it should now be able to list the contents.

Be aware that on OS/2, you must eject a USB drive before physically disconnecting it. Failure to do so may cause the drive to be marked as "dirty" and inaccessible until chkdsk is run. The easiest way is to use the "USB widget" on XCenter (from a commandline, you can also use "eject X:"). Also, be aware that once a drive has been ejected, it must be physically detached and reattached before it can be mounted again. As I'm sure you know from Win, FAT16 is horribly unreliable - particularly on flash drives - so the problem you've encountered is not all that unusual.

FWIW... I wrote all of the install-from-USB stuff in AOS as well as XCenter's USB widget ("RemMedia", by name), so I have a fair amount of experience dealing with this stuff...

I cannot believe that there is no solution for sending Ctrl-C to cmd.exe.

Of course there is.

As I understand it, you want the user of your PM-based editor to be able to press Ctrl-C or Ctrl-Break in your app to send a signal exception to cmd.exe. Your problem here is that these two keystrokes have no special meaning in PM and won't generate an exception. They're just keystrokes that show up in your message queue.

When you get one, call DosSendSignalException(pid, exception). 'PID' is the process you DosExec()'d. Exception is XCPT_SIGNAL_INTR or XCPT_SIGNAL_BREAK. I leave it to you to test whether this works.

Applications / XWP v1.0.13 GA
« on: January 15, 2020, 02:29:40 am »
XWorkplace v1.0.13 GA is now available.

New Features
  • XShutdown now provides a live Reboot List taken from your AirBoot/BootManager's menu. It is always up to date and requires no configuration (IBM BM support requires LVM). XShutdown's page in the Desktop's notebook has also been updated.
  • The Pulse widget now offers two types of graph: the standard line graph, and a new color-coded moving bar graph that shows average load across all cores. Other improvements include a faster line graph and fixed-position display text that shows when a core is offline.
  • An ACPI-based CPU Temperature widget has been added to XCenter, courtesy of David Azarewicz.
  • Initial Spanish language support has been provided by Alfredo Fernández Díaz.
Updates and Bugfixes
  • NLS - Lite versions will use the "LANG" environment variable to determine which NLS version to load; the behavior of XWP-Full is unchanged. Language settings for all versions can be overridden by putting this in config.sys: "SET XWP_LANG=xxx" - where xxx is a 3-digit country code that XWP supports (e.g. 039)
  • XCenter - 'Create new widget' has been added to all XCenter menus
  • Install/Remove - after uninstalling XWP, the "System" object will be recreated in System Setup the next time the Desktop restarts
  • See XWP Help's "Version history" topic for additional update details.
This version is available in both Full and Lite versions for German, English, Spanish, Italian, Japanese, and Dutch.


This only applies to PM apps. None of the DLLs listed in SYS_DLLS are loaded into VIO apps.

(3) Not all textmode programs do write into stdout, but there is text output shown nevertheless. This output gets shown in the hidden cmd.exe VIO window and not in my editor window. Can someone explain what this means and perhaps how to get this text in stdout nevertheless?

A VIO window is not a virtual TTY device. It's an emulation of a full-screen text mode session. In these sessions, the screen is accessed via the Vio API functions which can write anywhere on the screen independent of stdout/stderr. When an application like cmd.exe wishes to write stdout/stderr to the screen, it probably uses an internal version of VioWrtTTY().

To capture Vio API output, you would need access to the actual screen buffer used by full-screen apps or the virtual screen buffer used by VIO windows. Unfortunately, these buffers belong to other processes, so your app has no way to get at them.

Applications / Re: XWP and folder file size listing
« on: November 19, 2019, 03:34:53 am »
If all you're interested in is a larger command line window, add this to the "Parameters" field of whatever object you use to start 'cmd.exe':
/k mode 104,43

For the command line window that XWP adds to folder menus, I use this to increase the size and change the current directory:
/k mode 104,43 & cd %*

Another way to open a command line in the desired directory is to drop a file or folder on this object.

Applications / Re: XWP and folder file size listing
« on: November 16, 2019, 10:44:31 pm »
I was about to explain the cause but Gregg beat me to it, so I'll just add this: almost certainly, the culprit here is Doodle Screen Saver which you've been playing with lately. Did you have it installed previously?

FYI... my fix for this was to reset the FPU control word to what VAC expects every time a folder is about to be refreshed. This works most of the time but not always. I don't know why.

Pages: [1] 2 3 ... 8