Dir$ error

[Gösta H. Lovgren-2]

Just got PBWin 9 (all the kudos to PB everyone says). However when I copied this to try it out, it keeps "bomb"ing:

'

'PBWIN 9.00 - WinApi 05/2008 - XP Pro SP3
#COMPILE EXE
#INCLUDE "WIN32API.INC"
FUNCTION PBMAIN
 
 'Code clipped from Help File
LOCAL Listing$() '<<- had to add
DIM Listing$(1 TO 1000)
DIM x&, temp$
temp$ = DIR$("*.*", TO Listing(x&) ) 'Data type mismatch error
WHILE LEN(temp$) AND x& < 1000 ' max = 1000
  INCR x&
  temp$ = DIR$(NEXT, TO Listing(x&) )
WEND
END FUNCTION
 
 
'

[jcfuller]

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

James

[Gösta H. Lovgren-2]

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.

[jcfuller]

Listing$ TO Listing(x&)

[José Roca]

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:

#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

[Gösta H. Lovgren-2]

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)
============================================

[jcfuller]

Sorry Gösta I thought it was your code.

Steve you should know better than that

James

[Gösta H. Lovgren-2]

ANOTHER Error with Dir$ (code?)

LEN(temp$) is never zer0

'

'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
'

[José Roca]

LEN(temp$) is never zer0

In your code, of course not!

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

[Gösta H. Lovgren-2]

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
==========================================

[Michael Mattias]

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

 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

[José Roca]

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.

   DIM Listing(1 TO 1000) AS WIN32_FIND_DATA
   DIM x&, temp$
   x& = 1
   temp$ = DIR$("*.*", TO Listing(x&))
   MSGBOX Listing(x&).cFileName

[Michael Mattias]

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

[Michael Mattias]

>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().

[Cliff Nichols]

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 )

[Michael Mattias]

(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

[Michael Mattias]

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

[Michael Mattias]

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

[Aslan Babakhanov]

Will DIR$ work with WIN32_FIND_DATAW structure?

[José Roca]

I'm afraid not. You will have to wait for DIRW$.