Announcement

Collapse
No announcement yet.

Missing from 9

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Gösta H. Lovgren-2
    replied
    Eleven friends and only 5 goats and a virgin. Seems a little out of balance to me. Is that a shared inheritance (OOP) thing?

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • John Petty
    replied
    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

    Leave a comment:


  • John Petty
    replied
    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.

    Leave a comment:


  • Michael Mattias
    replied
    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.)

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • John Petty
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    Code:
    #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

    Leave a comment:


  • Michael Mattias
    replied
    >DATE$....without me having to write a conversion every time

    so write it once:
    Code:
    #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.

    Leave a comment:


  • John Petty
    started a topic Missing from 9

    Missing from 9

    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.
Working...
X