Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Failure to pass data to form

graand

Programmer
Jan 2, 2025
1
The following code has just thrown an unusual problem.
This will usually pass several file names to a form for display however today, being the first time it has been used in 2025, it failed.
The name format is ESMyymmdd.zip and hasn't had an issue for 20+ years. Today I find that it will not pass any name with the format ESM25mmdd.zip, it will however pass file names with the format ESM26mmdd.zip.

Thoughts?
1735792981545.png
 

Attachments

  • 1735791422958.png
    1735791422958.png
    13.9 KB · Views: 10
You should post code as code/text, not as image.
You pass in the string (that's a file skeleton or filter) 'ESM??????.ZIP'. That's completely unspecific to whatever could be in the position of any of the questionmarks.

How do you use this parameter in the form code? That's essential to find out why it doesn't find 2025 files. The other issue could simply be no ESM25... files exist to be unzipped. Well, most relevant is what you get from the file skeleton, and that's everything starting with ESM and having 6 further characters, any 6. That doesn't exclusde ESM25 files, unless you only have ESM25?????.zip files, for example, with ESM25, but more than 4 trailing characters after that, or less. You're only looking for files having exacly 9 characters overall, starting with ESM and with ZIP extension.
 
Last edited:
could you be having a SET CENTURY thing... is this only happened after the new year?
 
I'd trouble shoot by putting a suspend right after the adir(..) to see what's been captured and check against what's actually in the source folder at the same time.
 
Not even sure ADIR is used, the parameter looks like a file skeleton parameter as is used in ADIR, so it's likely, but unless graand doesn't post the code of the GETFIL2 form init receiving these parameters, showing what's done with them, we know nothing of value to help.

The meaning of a ? in a file skeleton is any character, but it must be a character, unlike * it doesn't stand for as many characters as you like. So in theory ESM??????.ZIP used as ADIR fileskeleton parameter should only list files with names that start with ESM, have 6 more characters, and then the file extension ZIP.

So I made up a showcase with 3 files:
ESM25011.ZIP - a too short name
ESM250101.ZIP - a name fitting the pattern
ESM250101a.ZIP - a name too long

I expected ADIR(laZips,"ESM??????.ZIP") to only create an array item for ESM250101.ZIP and not show the too short and the too long name, but it listed all three files. That's a bug, surely. But a bug that'll always show too many files, never too few files.

Turns out the number of question marks doesn't matter very much, I also get all 3 files from ADIR(laZips,"ESM?????.ZIP") or even ADir(laZips,"ESM????????.ZIP"). ADIR goes back to zero only with 4 or less question marks in the file skeleton parameter. Not sure whether VFP does the pattern matching or delegates that to Windows API and that changed. It may be 8.3 DOS file names used for filtering allow ADIR to start seeing results with 5 question marks, as these names are 9 characters long and have a short file name in the form of ESM???~?.ZIP, to which ESM?????.ZIP already is strictly fitting. Too many question marks should not work, but then maybe VFP/OS doesn't care for extra questionmarks when it gets to the file extension earlier.

Anyway, this bug or by design behavior won't effect you the way you say you're affected as it shows too many, not too few files.

Either you simply where in the wrong directory or you don't have any ESM25????.ZIP files or the code doesn't use ADIR at all and fails on something completely different. That call of the form doesn't tell what goes wrong, though. Only the code of the form itself would show what's going on.
 
Last edited:
Of course, Steve, what I'm talking about is the minimum information we need to put the finger on what's not working. It's not the file name pattern, that's all right. Even considering the bug it's not suppressing ESM25*.ZIP files.

Well, and on the other hand, debugging helps mostly with reproducible problems, if it's a one off problem to start in the wrong directory with the SET DEFAULT setting a new direcotry relative to that, debugging won't reveal what happened at the time the expected files were not displayed. In short, you can't debug a past case.

Then, one one side of the spectrum talking about "passing data" makes me think graand doesn't know simple terms, on the other side of the spectrum graand may have programmed the GET_FIL2 form because he knows of the flaws of ADIR, programmed his own filtering of names that has its own flaw. Impossible to know without having more threads for comparison, as graand is a new user.

I assume the problem is solved, was a "duh" moment to not come back to. We'll see. I still give your idea of debuggin a thumbs up. The first thing to look into would be the Locals window, showing the array ADIR created, which will be shown in a treeview with all its elements. Add an entry Sys(5)+Sys(2003) to the watch window to see the current/defult directory and whether it's actually what you expect. But again, if this works in the dev environment, you still don't know what caused the case. Maybe the whole application depends on teh default directory to usually be the application directory, some code - like this one - changes it, but also changes it back. And some brnach of the code does not. That's a scenario where you will have a hard time reproducing the problem even using the debugger, as you have to know which branch of code to execute beforehand that sabotages that dependency of the current directory.
 
Last edited:

Part and Inventory Search

Sponsor

Back
Top