[b] 2 december 2014[/b]
[b]Full operational working of set dateformat and new internal variables concerning file's datestamp.[/b]
The Gui4Cli.guide of OS3 versions stated the possibiity to modify the dateformat. This was not implemented though
set dateformat number
the numbers [0-5] correspond to the
#define FORMAT_DOS 0 /* dd-mmm-yy */
#define FORMAT_INT 1 /* yy-mmm-dd */
#define FORMAT_USA 2 /* mm-dd-yy */
#define FORMAT_CDN 3 /* dd-mm-yy */
#define FORMAT_DEF 4 /* use default format, as defined */
#define FORMAT_ISO 5 /* yyyy-mm-dd (ISO 8601) */
Dateformats influenced are:
- the internal variables values concerning system time
$$SYS.DD (day order nr in the month)
- the internal variables concerning a file's datestamp
- new internal variables
- the new internal variable
$$FILE.DAY gives you the weekday name of the file's datestamp
just as the existing system time internal variable $$SYS.DAY
For consistent results DDay DMonth & Dyear can be used both for SYS & FILE internal variables .
File requesters (FILEREQ command) and Directory listviews are not affected by a dateformat change, but both can be ordered easily according to datetimestamp.
6 march 2014
As i have been silent here for a long time I prefer to start a new "progress" report
1. About the source
- I have been working lately on the Gui4Cli- source so as to bring it completely up to date with latest SDK.
(no obsolete or deprecated functions any more) and all warnings except of the "differ in signedness" variety were taken care of.
- added more mathematical functions (all the unary math.h functions are presently available, also the % modulo function can now be used in Gui4Cli mathematical expression evaluation $( math_expression)
- improved checks and error reporting based on the expected number of arguments (in parser2.h,)
Newly loaded Gui4Cli program used to crash if the number of argumenst for some commands was too low.
- SetGadValues used to crash when the program/gui was loaded with empty listviews or with directory listviews. that showed the devices (not a directory) Although some improvement, the best is to avoid these cases.
- Stability is imho very good.
Todo (limited list)
- the internal vriables about files $$file.time, $$file.date,etc may crash the program (The clean up seems to have introduced this problem)
- cleanup the source for the Printf statements
2. About the Gui4Cli launcher
The Gui4Cli launcher is still written in 68k code (it was named "gui", but was renamed to "gui4" to avoid confusion in OS4) . It gives problems when used as the default tool in an icon. A freeze occurs when after such a launch you quit Gui4Cli and then again click on an icon with gui4 as default tool.
No problem though when you use gui4 to launch some Gui4Cli scripts from shell, over and over again.
I therefor launch only the first Gui from an icon, during a computing session. Don't see the need to quit, as i never quit arexx either.
You can use Gui4Cli in the role of a default tool for an icon, But you will not get the WB path information.
This limits you in addressing directly some applications "in the path"
eg CLI 'Notepad $Myfile'
will not recognise Notepad
3. About Gui4Cli programming
I recently also made a big overhaul of my Gui4Cli programs, (i mast hav hundreds on my HD) using the power of the "sharemenu" command.
See my tutorial http://www.os4coding.net/blog/josduchit/gui4cli-reusing-code-sharemenu-way
5 march 2014
Improved the error catching for a newly loaded gui.
Commands requiring at least one argument such as GuiQuit and GuiOpen won't crash any more when no argument is given