Announcement

Collapse
No announcement yet.

Dir$ error

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

  • Michael Mattias
    replied
    > You will have to wait for DIRW$

    Or use this until then: Directory List with Non-ASCII (Unicode) characters in file names 5-31-08

    Leave a comment:


  • José Roca
    replied
    I'm afraid not. You will have to wait for DIRW$.

    Leave a comment:


  • Aslan Babakhanov
    replied
    Will DIR$ work with WIN32_FIND_DATAW structure?

    Leave a comment:


  • Michael Mattias
    replied
    An extra note for the "applications interested."

    ASNs are used extensively in several industries.. notably retail.

    While not true in this particular case, "late, inaccurate or missing ASNs" result in back-charges to the vendor. For example, K-Mart charges vendors on an "$X per purchase order plus $Y per item"" basis. These amounts are simply debited to the vendor and deducted from the customer's next payment.

    That is, in many many cases errors in ASNs (eg here, the six missing documents) result not only in the customer service time required to deal with the problem by re-creating and sending, but a direct hit to the bottom line, too.

    MCM
    Last edited by Michael Mattias; 30 Aug 2008, 09:13 AM.

    Leave a comment:


  • Michael Mattias
    replied
    Just a little real-life story from this week, more or less related:

    My client in Paris (no, not that Paris, they are in Paris Arkansas) has had it drilled into their heads (and it's in the doc, not that they read it) that when some software I wrote does not automatically dismiss the final on-screen progress dialog, "something bad happened and you need to check it out."

    If they can't figure it out themselves (98% of the cases), they are to make an entry in the "trouble log" and drop me an email (or call me if production) so I can check it out.

    This week I had to convert one of their programs to support changes in the ERP system. So, what I did was copy off the software and the most recent production input data to a "development" folder, and run it there to create a 'baseline' output ... which was what my desired output from the new software SHOULD be... that is, the file I create for their customer with the new software should be identical to that produced by the current software.

    Well, when I ran the task I got the final progress dialog 'not dismissed' with a big ole' error message right on the screen. Say what?

    So I went back to the production audit log (a very cryptic report produced by the Mercator mapping tool - totally user-hostile) and found that when they last ran the job "live" they had the same error!

    So I did a little checking.

    What the output of this job is is an ANSI ASC X12 "856 Advance Shipping Manifest" document ("ASN" is commonly used as a TLA, even though it should be "ASM"). When this file is submitted to the customer as a notice of shipment, my client will be paid for the merchandise.

    By ignoring the message provided, it turns out my client only sent eight (8) of the fourteen (14) documents which should have been sent. Meaning, in about thirty days someone in Paris' Accounts Receiveable Dept will be wondering why the customer did not pay for almost half the merchandise. The customer has no problem: "You never sent me the document, meaning you did not ask to be paid."

    My point?

    ALWAYS report errors and inconsistencies to the software publisher!!! The little bit of time it takes to file the report will be repaid on other ways many times over.

    And anyone who is themself a developer (um, which kind of by definition includes everybody here except the "pure hobbyists") will tell you they WANT these reports.

    Why? Because we'd prefer to "fix it once" than to "deal with it many times!"




    MCM

    Leave a comment:


  • Michael Mattias
    replied
    (Just razzing a lil...but truthfully, when you can't find docs to say you are right (lazy documentors) then you must take your best guess and trust your gut
    No, you should not do that.

    What you should do is take advantage of the fact PB Support accepts email and ask.

    Think about it for a second. In the absence of documentation for each member of the "new DIRLIST structure predefined by the compiler," what good is it? Why even bother to use this great new feature?

    In this case I would bet - a lot - it's just a documentation oversight which will be corrected in a "9.01" release. But until the doc is updated I have zero compunction about asking support for an explanation.

    MCM

    Leave a comment:


  • Cliff Nichols
    replied
    Quack

    What if its a swan???

    if it works...great...if not then later you may have a time figuring out why in most cases you hear quack...and all the sudden you hear "AUGGGHHHH"


    (Just razzing a lil...but truthfully, when you can't find docs to say you are right (lazy documentors) then you must take your best guess and trust your gut )

    Leave a comment:


  • Michael Mattias
    replied
    >You can replace DirData with WIN32_FIND_DATA if you want

    That's because the compiler (thru 8x) does not check passed UDT parameters member-for-member, it only checks the total SIZEOF().

    Leave a comment:


  • Michael Mattias
    replied
    >If it looks like a duck, walks like a duck, and quacks like a duck...

    If it were a duck, the help file would say it's a duck.

    Leave a comment:


  • José Roca
    replied
    That looks suspiciously like a standard Windows "WIN32_FIND_DATA" structure, although the on-line doc for Win/9 does not make that claim.
    If it looks like a duck, walks like a duck, and quacks like a duck...

    You can replace DirData with WIN32_FIND_DATA if you want.

    Code:
       DIM Listing(1 TO 1000) AS WIN32_FIND_DATA
       DIM x&, temp$
       x& = 1
       temp$ = DIR$("*.*", TO Listing(x&))
       MSGBOX Listing(x&).cFileName
    Last edited by José Roca; 29 Aug 2008, 09:00 AM.

    Leave a comment:


  • Michael Mattias
    replied
    Code:
    TYPE DirData
     FileAttributes AS DWORD
     CreationTime AS QUAD
     LastAccessTime AS QUAD
     LastWriteTime AS QUAD
     FileSizeHigh AS DWORD
     FileSizeLow AS DWORD
     Reserved0 AS DWORD
     Reserved1 AS DWORD
     FileName AS ASCIIZ * 260
    ShortName AS ASCIIZ * 14
    END TYPE
    That looks suspiciously like a standard Windows "WIN32_FIND_DATA" structure, although the on-line doc for Win/9 does not make that claim.

    It would be nice if that were the case since that would mean these members ...
    Code:
     CreationTime AS QUAD
     LastAccessTime AS QUAD
     LastWriteTime AS QUAD
    .. are actually standard Windows' FILETIME structures, meaning doing a PB "DIR$" command would be all you need to get the file timestamp... a 'frequently asked question' over the years...

    I'll drop PB support a note and see if I have made a good guess; and if so suggest this info be added to the help file.

    MCM

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    Originally posted by José Roca View Post
    In your code, of course not!


    It will grow, and grow, and grow...
    Oh boy. Am I chagrined. In my experiments, somehow I just got confused.

    Thanks, Jose

    ==========================================
    Death is a friend of ours;
    and he that is not ready to entertain him
    is not at home.
    Sir Francis Bacon
    ==========================================

    Leave a comment:


  • José Roca
    replied
    LEN(temp$) is never zer0
    In your code, of course not!

    Code:
    temp$ = temp$ & Using$("### ", Len(Temp$))& Dir$(Next, To Listing(x&)) & $CrLf
    In each iteration, you are adding to temp$ Using$("### ", Len(Temp$)), the result of Dir$(Next, To Listing(x&)) and $CrLf.

    It will grow, and grow, and grow...

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    ANOTHER Error with Dir$ (code?)

    LEN(temp$) is never zer0

    '
    Code:
    'PBWIN 9.00 - WinApi 05/2008 - XP Pro SP3
    #Compile Exe
    #Include "WIN32API.INC"
    Function PBMain
       Dim Listing(1 To 1000) As DirData
       Dim x&, temp$, drs$
       x& = 1
       temp$ = Dir$("C:\Power Basic\PBWin9\bin\*.*", To Listing(x&))
       
       While Len(temp$) And x& < 1000 'Len(Temp$) never 0?
                                      'Seems to add each Len
         Incr x&
         temp$ = temp$ & Using$("### ", Len(Temp$))& Dir$(Next, To Listing(x&)) & $CrLf
       Wend
       ? temp$
    End Function
    '

    Leave a comment:


  • jcfuller
    replied
    Sorry Gösta I thought it was your code.

    Steve you should know better than that

    James

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    Thanks Jose, the code shown is appreciated. {grin}

    (Note I had caught the X=1 before I posted as I saw Listing$ dimmed 1 to 1000 and knew there would be an Lbound error with the first Dir$. Of course it never ran far enough to trip an Lbound.)

    Never occurred to me the array had to dimmed with AS DirData.

    PB must never have tried the example. Just an oversight I guess.

    ============================================
    Thus conscience does make cowards of us all;
    William Shakespeare (1546-1616)
    ============================================

    Leave a comment:


  • José Roca
    replied
    The DIR$ function may optionally assign the complete directory entry to an appropriate UDT variable if you include the TO clause as a parameter. The complete directory entry contains 318 bytes of data, corresponding to the following TYPE definition. This definition (DIRDATA) is built into PowerBASIC, and need not necessarily be included in your source code.

    TYPE DirData
    FileAttributes AS DWORD
    CreationTime AS QUAD
    LastAccessTime AS QUAD
    LastWriteTime AS QUAD
    FileSizeHigh AS DWORD
    FileSizeLow AS DWORD
    Reserved0 AS DWORD
    Reserved1 AS DWORD
    FileName AS ASCIIZ * 260
    ShortName AS ASCIIZ * 14
    END TYPE

    You can declare a variable as DIRDATA for this purpose, or use any other user-defined type of at least 318 data bytes. The additional data may be used for any other purpose in your program.
    Use this code instead of the one in the help file:

    Code:
    #COMPILE EXE
    #INCLUDE "WIN32API.INC"
    
    FUNCTION PBMAIN
     
       DIM Listing(1 TO 1000) AS DirData
       DIM x&, temp$
       x& = 1
       temp$ = DIR$("*.*", TO Listing(x&))
       WHILE LEN(temp$) AND x& < 1000 ' max = 1000
         INCR x&
         temp$ = DIR$(NEXT, TO Listing(x&))
       WEND
    
    END FUNCTION

    Leave a comment:


  • jcfuller
    replied
    Listing$ TO Listing(x&)

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    Originally posted by jcfuller View Post
    Come-on Gösta you're a better programmer than that!!!

    James
    Better than what? {No code shown}

    I posted here because I couldn't get it to work because of a Data Type Error and I don't find out why.
    Last edited by Gösta H. Lovgren-2; 28 Aug 2008, 01:24 PM.

    Leave a comment:


  • jcfuller
    replied
    Come-on Gösta you're a better programmer than that!!!

    James

    Leave a comment:

Working...
X