Missing from 9

[John Petty]

I am very pleased with what I have seen in PBWIN 9 and don’t want to start another long wish list but found a couple of small annoyances not improved (but the again as Michael would tell me probably haven’t sent the correct suggestions).
I like to timestamp many simple log files. It would be nice if DATE$ recognised locale so my clients and myself knew that 1/3/08 is 1st march without me having to write a conversion every time to handle the country it is being used in.
WRITE has been improved but from the documentation still does not guarantee an output that can be read by INPUT. I have tested almost every version of MS basic products from the original IBM Basic and GWBasic, Windows for DOS, VB 1 thru 6 and most PB versions (except 9 of course) and not one can actually read accurately what is written with WRITE. Would be nice if they could WRITE and INPUT true CSV format as Excel does, actually not very hard.

[Michael Mattias]

>DATE$....without me having to write a conversion every time

so write it once:

#INCLUDE "PBDateToFormattedDateWhichIsLocaleAware.INC"

WRITE has been improved but from the documentation still does not guarantee an output that can be read by INPUT

It should. Show failing code.

[Michael Mattias]

#INCLUDE "Win32api.INC" 
FUNCTION LocaleDate (OPTIONAL BYVAL Longdate AS LONG) AS STRING

  LOCAL szDate AS ASCIIZ * 128
  LOCAL st   AS SYSTEMTIME

  GetLocalTime   st

  getDateFormat  %LOCALE_USER_DEFAULT,_
                  IIF&(LongDate, %DATE_LONGDATE, %DATE_SHORTDATE) ,_
                  st, BYVAL %NULL, szDate, SIZEOF(szDate)

  FUNCTION = szDate
END FUNCTION

FUNCTION PBMAIN () AS LONG
    
    MSGBOX LocaleDate (0) ,,"default"
    MSGBOX LocaleDate (1) ,, "Long date"
    
    
END FUNCTION

[John Petty]

Michael
As an old DOS basic programmer I am surprised you have never seen the problem. Don't have 9 yet to test but from the manual

For best results, strings should not contain quotation marks, as these may interfere with the expected output format.

the only simple spec I know that can WRITE any string with a matching INPUT is if they are CSV compliant. Is not a very hard spec.
As for DATE$ why buy a compiler if you are going to add replacement code for the functions or statements. PB has a large international market and as you correctly show it is a simple fix, so why not have it right in the first place?
John

[Michael Mattias]

the only simple spec I know that can WRITE any string with a matching INPUT is if they are CSV compliant. Is not a very hard spec.

As an "old DOS BASIC progammer" (your words) I have seen at least 6,864 versions of files which have been called "CSV" . Where exactly might one find the documentation for this purported "simple spec" defining "CSV compliant?"

As for DATE$ why buy a compiler if you are going to add replacement code for the functions or statements. PB has a large international market and as you correctly show it is a simple fix, so why not have it right in the first place?

It's not a "replacement," it is an "enhancement;" and since DATE$ does what it promises to do, it does not require a "fix."

You wanted more; however, apparently you lack either the the required skills, imagination or initiative to do it for yourself.

Sheesh, Phil Gramm is looking righter and righter every day. (That would be the "Nation of whiners" Phill Gramm)

MCM

[Michael Mattias]

Besides, what kind of designer would use comma-quote delimited format to hold data which itself contains commas and/or quotes?

(I know the answer, but it would violate forum rules to print it.)

[John Petty]

While there have been a number of minor variations and though not formal RFC 4180 is I think generally accepted these days. Why would you allow it? Because it is a standard part of the English language and so a STRING should be able to contain all of the language (or any other language for that matter) and be output correctly so other programs such as spreadsheets and even the same compiler that wrote the output should be able to read it back in as originally typed.
As for DATE$ obviously do have the knowledge because as my original post said if you bothered to read carefully have always had been able to correct it. Are you one of those people who buy a car then immediately changes the engine because a better one is available?
I note you have made many many requests for improvements to the compiler, but if someone else has the audacity to suggest an improvement you call them a whinger.

[John Petty]

Michael
Must be nice to have such a simple life as you do

Besides, what kind of designer would use comma-quote delimited format to hold data which itself contains commas and/or quotes?

(I know the answer, but it would violate forum rules to print it.)

I know you only have to worry about rules in your own country for programs that are only used in that country.
Some of us have to do things like extracting information from one programs data bases (of all types) from one program to input into a competing program when the user has decided to change. Not surprisingly the losing supplier is not very helpful, so can require quite a bit of reverse engineering. The new suppliers normally have limited programs for importing the transferred data which in most cases can be done with a true CSV (not something just called .CSV).
There are still some countries that have resisted the metric system so the use of double quotes as a standard abbreviation for inches in product descriptions is common and I have even seen people use commas in descriptions (how dare they, haven’t they heard Guru Michael’s rules of the perfect world)
Hope I didn’t break any forum rules with my reply.
John

[Michael Mattias]

I note you have made many many requests for improvements to the compiler, but if someone else has the audacity to suggest an improvement you call them a whinger

Requests for enhancements should be sent to [email protected].

I have never posted a suggestion here for which I did not send an email to above. This is probably why I got a number of the important (to me) features this time.

There are only two reasons to post a New Feature Suggestion here:

• To encourage others to use the officially-sanctioned communications venue to request the same thing; "it is said" the more who ask, the better the chance of actually seeing that new feature.
• To whine about it not being in this release

I shall look for RFC4180; I had never heard of that before.

MCM

[Michael Mattias]

I found RFC4180. (Thank you, Google!)

Neither INPUT# nor LINE INPUT# + PARSE$ will handle all defined cases. (the embedded CarriageReturn/Line feed is the killer)

You'll have to write your own function or submit an NFS.

I think you could improve the chances of seeing some kind of intrisic function implemented in the PB compilers if, after you send it in the NFS, you were to conduct a small ceremony with eleven friends during which you sacrifice five goats and one virgin.

MCM

[Gösta H. Lovgren-2]

Eleven friends and only 5 goats and a virgin. Seems a little out of balance to me. Is that a shared inheritance (OOP) thing?