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 - Andreas Schnellbacher

Pages: [1] 2 3 ... 49
Programming / Re: Passing env vars to an nmake process
« on: October 20, 2021, 10:23:59 pm »
Found a solution with a temporary file:

queryvar.cmd was changed to write DIR1=Value to STDOUT. Then I call

Code: [Select]
queryvar.cmd > tmpfile

tmpfile is then included within a pseudo target.

Because !include is expanded by the preprocessor, tmpfile must exist when the preprocessor runs the !include line. That is achieved by using

Code: [Select]
!if [queryvar.cmd > tmpfile]

All together:

Code: [Select]
!ifndef DIR1
! if [queryvar.cmd > tmpfile]
! endif
! include tmpfile
   @echo DIR1 is defined after including tmpfile as: $(DIR1)

(It's heavily simplified compared to my original, hopefully I didn't break it.)

Any more ideas?

Programming / Passing env vars to an nmake process
« on: October 20, 2021, 01:09:32 pm »
I'm using IBM nmake. During processing of the main makefile, I would like to import values set by an external .cmd, let's name it queryvar.cmd. These vars should be used in pathnames to call e.g. an OS/2 copy command.

Code: [Select]
#  queryvar.cmd should set DIR1
   copy $(DIR1)\sub1\file.1 G:\

How can a value be passed from queryvar.cmd to the running nmake, so that it can be used as $(DIR1) in the example above?

It works well when setting env vars before calling nmake. But in this case nmake is already started. It won't matter for me if queryvar.cmd really sets env vars or just returns the value of one env var only.

Applications / Re: xWorplace - xCenter issue(s)
« on: October 08, 2021, 09:12:57 am »
I use Andi's version as well, solely because of the changed shutdown delay. I don't have Turbo Folders activated. Ulrich's bug tracker is not available anymore, but there are some bugs with it.

Actually, you really do not want those extra features.
Good to have someone who knows what people have to want. ;-)

Applications / Re: xWorplace - xCenter issue(s)
« on: October 07, 2021, 12:56:42 am »
The "Add Widget to Tray" option is clearly missing from the popup menu.  You can see two lines in the menu where the option is supposed to be - but no option.
Yes the screenshots and the full term make that clear. BTW: That's not XCenter's context menu, but the tray's. Looks like a bug to me. I usually don't use the tray much, because I've two XCenters. BTW: Not all widgets can be placed in a tray.

The conclusion is at this point in time there is no easy way for AOS customers who want to run the lastest version of full xWorkPlace to get the removable media widget installed.
It seems to be much easier to me to extract the files from ANXWP_EN.WPI and copy them to the plugins\xcenter dir.

In such a case I run: wic <wpifullfilename> -x in the newly created dir <wpiname>. That unpacks all files, except the script file.

Applications / Re: xWorplace - xCenter issue(s)
« on: October 06, 2021, 08:16:06 pm »
Installed xWorkPlace 1.0.13 which I got from Netlabs. The Add Widget option on the xCenter popup menu is missing.
Quite unlikely. For older XWP versions you have to catch an edge of the xCenter to get the correct context menu (xCenter's instead of a widget's). Rich has changed that, in 1.0.13 or earlier. Since then the 'Create new widget' menu item is also present in a widget's context menu, below 'Delete widget'.

If 'AN Removable Media Monitor' is not available in the 'Create new widget' submenu, then it's not installed (the DLL wasn't found). If it's grayed out, then it's already installed. Some widgets can only be installed once per xCenter. The installed ones can also be viewed in XCenter's properties dialog, tab 'Widgets'. To complete that: XCenter's WPS setup string can be altered by an XWP 'Setup string' object. That's also useful for save and restore.

Applications / Re: xWorplace - xCenter issue(s)
« on: October 06, 2021, 07:53:55 pm »
To 2) Yes, there exist special versions for ArcaOS. They contain the AN removable media monitor widget files.

The files are:
plugins\xcenter\RemM_en.ms1 (rename to .msg if not already)
plugins\xcenter\RemMedia.xqs (optional, for bug report only)

Utilities / Re: MultiUser support for OS/2
« on: September 24, 2021, 07:57:47 pm »
There already exist a few packages for that. Some disadvantages are:
  • More shared memory consumption
  • No real security because the OS doesn't provide that.
IMO multi-user is a feature for business systems and networking. It's a long time ago since OS/2 was used for that.

Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: September 21, 2021, 03:47:51 pm »
Same from me.

Off Topic discussions / Re: Lo Res Car?
« on: September 09, 2021, 09:03:32 pm »
Wrong forum.

Man I *love* RPM....
One problem is that yum itself uses Python.

Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: September 04, 2021, 12:38:32 am »
I agree. It shows that every classification needs to be maintained. Some thoughts:

To 1)

apps/internet is really not useful nowadays. OTOH has it useful subdirs (protocols) that makes it easy to find e.g. Thunderbird. apps/comm doesn't really make sense in a parallel dir.

apps/graphics and apps/multimedia: Use either a few (max. 10) more top-level dirs or many same-level dirs, but not both. It depends on the structure you have for this. I prefer more the first and wouldn't make it depend on what is now on Hobbes only. It's better to avoid trees with complete different amount of elements on the same level.

I would rather place the other smaller trees that have a too high level below useful top levels.

Another thing is single files in a dir that has other subdirs. Should they rather be placed in a "misc" dir below that? Then "misc" would make sense.

I guess you have already thought about most of them.

To 2)

These two misc dirs contain far too many items. I agree that most of them belong rather to other dirs.

To 5)

5.1) "remote". But rdesktop really in apps/internet/misc?
5.2) "filesharing"
5.3) "xworkplace\widgets"

(I prefer rather short names, but I always stumble about "wp" which should rather be "wordproc" and "dtp", IMO.)

Some other thoughts:

About Thunderbird: I would prefer to place Lightning beneath Thunderbird, not in apps/calendar. After moving them, the rest of app/calendar doesn't need such a high dir level.

About apps/wp: Acrobat Reader (not Distiller), IBM BookManager, PDFMerge and the GNU libs don't belong here. (I've just found that you've already mentioned PDFMerge in an earlier message.)

I'm not sure where to place programs and viewers an tools for special formats. I have here placed them in subdirs below "Format", but I don't like "Format" anymore. It's not that easy as it seems. Someone has to have a good idea for that.

About util: What's the criterion to place it here or in apps, esp. regarding the current contents of apps? I would drop that and move it rather to apps.

How is your planned structure?

Programming / Re: REXX - Top header comments Suggestion
« on: August 24, 2021, 04:14:07 pm »
I use the headers Christian has created for several filetypes.

The REXX header prototype is header.cmd_rex. An example is icons.cmd. (SVN would have expanded the $Id$ line. Trac as well, but it refuses to display .cmd files.)

An example for another header I've used for another project is:
Code: [Select]
* pmcall.cmd
* Version: 2019-08-11
* Syntax: pmcall.exe  [-m] [-b] [-l <log_file>] <cmd_name> [<cmd_args>]
*    -m  Messages enabled (STDOUT and STDERR/PM)
*    -b  Error beeps enabled
*    -l  Logging enabled
*    -h, -?  Show help message
* Provide a PM environment for .cmd files.
* o  It opens a queue, whose name is provided as env var 'ERRORQUEUE'.
* o  It executes the submitted cmd_name and its args.
* o  After execution of cmd_name, It reads the contents of ErrorQueue and
*    presents it in a PM message box. This is useful in cases where messages
*    would be lost otherwise.
* o  This is compiled to a PM executable to make the submitted cmd_name run
*    in a PM env: REXX2EXE /P [/K] pmcall.cmd pmcall.exe
* Part of the DOSBox installation. May also be used for other cases.
* By Andreas Schnellbacher <mailto:###>
* Contains REXX code from the NEPMD project.

Yes, the message is gone, as Mike describes. Thanks.

But the old problem remains: The logon to the main page ( isn't permanent, while it is to the SMF pages, which seems to use the cookie 'SMFCookie...'. The cookie 'joomla_remember_me_...' shows an expiration date of 2021-08-25 (in a month), but apparently that doesn't work and the logon lasts only for the session. Maybe the additional session cookie applies here.

Applications / Re: FeatherPad for OS/2
« on: July 14, 2021, 10:42:39 pm »
And how do we contact Silvan?
Email to bww? Or just wait a bit, he scans the fora from time to time and was very responsive in the past. Additionally: It's vacation time.

Pages: [1] 2 3 ... 49