Author Topic: Setup strings with PARSEDB and DATABASE.DAT  (Read 368 times)

Doug Clark

  • Jr. Member
  • **
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 99
    • View Profile
Setup strings with PARSEDB and DATABASE.DAT
« on: November 16, 2018, 11:10:12 pm »
When creating or updating a Program Object it appears the WP_PROGRAM object in the WPS searches DATABASE.DAT when you cursor off the "Path and file name" on the Program tab of the program object and updates various settings on the program object based on the settings in DATABASE.DAT.

(This is described starting on page 122 of Redbook GG24-3731)

DATABASE.DAT is created/updated by PARSEDB.EXE based on text in DATABASE.TXT and "tags" in DBTAGS.DAT.

I was hoping I could add a new "tag" in DBTAGS.DAT that equals a setup string, make an entry in DATABASE.TXT/DATABASE.DAT with the setup string for a program, and have the Program Object execute the setup string when the user types a executable name in the "Path and file name" entry field.  But alas, it does not work.

Has anyone messed around with PARSEDB and DATABASE.DAT and created new tags to add settings to DATABASE.DAT that worked?

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 38
  • -Receive: 9
  • Posts: 388
    • View Profile
Re: Setup strings with PARSEDB and DATABASE.DAT
« Reply #1 on: November 21, 2018, 12:39:03 pm »
Has anyone messed around with PARSEDB and DATABASE.DAT and created new tags to add settings to DATABASE.DAT that worked?

Typically creating an own INST-ALL.CMD Rexx app will be more efficient than creating DATABASE.TXT entries, for one because DATABASE.TXT works better with unique files names. If you are going to append an INTERRUPT_DURING_IO to a customized DATABASE.TXT file, then you may as well insert INTERRUPT_DURING_IO in your own file. Without file format restrictions.

In theory you can use WPTOOLS.DLL to create setup files based on actually installed apps. Please note that both WPTOOLS.DLL and DATABASE.X may nowadays set a setting to its default value, like an useless PROGTYPE=PM for the first E.EXE or VIEW.EXE found in your PATH.

I'm not familiar with PARSEDB, but WPTOOLS.DLL to query existing settings may be easier. Nevertheless I wouldn't mind a generic DATABASE.TXT update, to e.g. exclude outdated versions and to include more modern apps.

Doug Clark

  • Jr. Member
  • **
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 99
    • View Profile
Re: Setup strings with PARSEDB and DATABASE.DAT
« Reply #2 on: December 03, 2018, 12:13:29 am »
The WPS is designed to be modified and there are modifications to WPS objects by DragText and xWorkPlace - just to name two. Each of those "modifications" have added features to WPS Objects - for example DragText adds tabs to the WPProgram object for Environment and Schedule.

The original WPS program object was written to use the entries of DATABASE.DAT to update the options/settings of the original program object. Which makes sense, but doesn't accommodate future enhancements or modifications to WPProgram objects. I was hoping there was a feature in the tags used by WPProgram/Database.dat that would allow the current mechanisim used by WPProgram and DATABASE.DAT to also be used for options/settings for future enhancements to the Program Object that were unknown at the time OS/2 was first created. Setup strings in DATABASE.DAT would have done that - but alas it appears they didn't think about that at the time.

I suppose it would be possible to subclass WPProgram and add a something that also scans another database, say DATABASE.STR, for setup strings and execute those setup strings every time the "Path and file name" entry on the Program tab is changed.

As you point out, using the application file name as the index into the database can cause some unwanted settings when you have two different programs with the same file name that require different settings.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 38
  • -Receive: 9
  • Posts: 388
    • View Profile
Re: Setup strings with PARSEDB and DATABASE.DAT
« Reply #3 on: December 03, 2018, 03:59:36 pm »
As you point out, using the application file name as the index into the database can cause some unwanted settings when you have two different programs with the same file name that require different settings.
That may be a type of overengineering. I guess you can write a rather simple database app which has recorded settings in the usual WPS setup string format, and - if you really want that - which queries settings of existing objectsand repairs broken ones.

Presumably a real new setting, a WPS setup string with "SET FOO=BAR" was already supported but not visible, comes with an own new setup string. E.g. "SCHEDULED=20121231235959".

My database is Rexx-shaped, because e.g. inserting a "SET FOO=BAR" or "ICONFILE=..." is easier that having to create and/or use some DATABASE.TXT format with exactly the same setting. I do still use DATABASE.TXT for a few Win-OS/2 apps, like MS Office's (not really motivated to find out differences compared to defaults and DATABASE.TXT).

I wouldn't mind having a customized/personalized or improved/modernized DATABASE.TXT, but an own Rexx script which contains both the data (SET FOO=BAR) and the data processing (a.o. SysCreateObject) is more efficient.

I could create records, like a customized record #1 with SET FOO=BAR and ICONFILE=... in a text field.

FWIW, ivan may be listening: the Rexx code is easy if you know the environment. Typically just lines with SysCreateObject, SysCreateShadow, SsSetObjectData or SysIni. Almost a configuration file instead of a computer program.