Hi ,Dubslow
Nice work.
I think you can increase version.

[QUOTE=msft;301029]Hi ,Dubslow
Nice work.[/QUOTE]Sadly, it doesn't work quite yet. :razz:

I think we'll increase the version when we get flash's crashes fixed :smile:

[QUOTE=Dubslow;301026]:huh:
LaurV, can you reproduce this?
[/QUOTE]
Yes. Original flash's files, all versions. When no ini file is in the folder (or it has different name, OR there is a # sigh in the front of "WorkFile=worktodo.txt" line) the command "CL -d 0" (where CL is how you renamed the exe file) [B]exits normally[/B], after printing my device capabilities, it says "Can't open workfile" and exits. If i delete the # sign, but change the name into "WorkFile=cucurigu.txt", then the same command exits normally, saying "Can't open workfile cucurigu.txt".

But then, if the line is not commented out, and the name of the file exists on the folder (that is, I have a valid worktodo.txt file there) then it crashes without no error message after displaying my device capabilities, in less then a second.

If worktodo is empty or contains garbage, then it exists normally with "No valid assignment found".

Any other combination that has the exponent given in the command line it works.

[QUOTE=LaurV;301067]...But then, if the line is not commented out, and the name of the file exists on the folder (that is, I have a valid worktodo.txt file there) then it crashes without no error message after displaying my device capabilities, in less then a second.

If worktodo is empty or contains garbage, then it exists normally with "No valid assignment found".[/QUOTE]

Exactly what I'm experiencing. I'll try to figure it out also. It's probably in the changes made going to 'safe' functions.

[QUOTE=flashjh;301069]Exactly what I'm experiencing. I'll try to figure it out also. It's probably in the changes made going to 'safe' functions.[/QUOTE]

Have you guys tried running the program under the control of a debugger?

Often saves a lot of time....

[QUOTE=chalsall;301072]Have you guys tried running the program under the control of a debugger?

Often saves a lot of time....[/QUOTE]
Not yet, that's next after I compile the next revision Dubslow posted.

[QUOTE=LaurV;301067]Yes. Original flash's files, all versions. When no ini file is in the folder (or it has different name, OR there is a # sigh in the front of "WorkFile=worktodo.txt" line) the command "CL -d 0" (where CL is how you renamed the exe file) [B]exits normally[/B], after printing my device capabilities, it says "Can't open workfile" and exits. If i delete the # sign, but change the name into "WorkFile=cucurigu.txt", then the same command exits normally, saying "Can't open workfile cucurigu.txt".

But then, if the line is not commented out, and the name of the file exists on the folder (that is, I have a valid worktodo.txt file there) then it crashes without no error message after displaying my device capabilities, in less then a second.

If worktodo is empty or contains garbage, then it exists normally with "No valid assignment found".

Any other combination that has the exponent given in the command line it works.[/QUOTE]
Thanks, that helps to narrow it down.

What about if you put non/valid assignments into cucurigu.txt, or whatever non-default name?

What about if you comment-out the WorkFile option, but then put a workfile name on the command line?

Edit: If you don't specify the workfile anywhere (e.g. comment-out WorkFile and don't say anything on the command line) does it still say "Can't open workfile" even if the file exists?

Edit2: Is it accurate to say that it simply cannot parse a proper worktodo line, regardless of workfile name and/or how said name was passed to the program? If that's the case, what about if you try "Test=//" or something like that? "Test=N/A,86243,//" or "Test=//86243" or "Test=N/A,,//86243"? There's not too much that could cause platform-dependent errors... strstr(), strtoul(), isspace(), fgets(), ...

[QUOTE=chalsall;301072]Have you guys tried running the program under the control of a debugger?

Often saves a lot of time....[/QUOTE]
The problem is the only one who's currently "fluent" in the code is the only one for whom it works :razz: If my debug build doesn't help, then maybe we'll see about getting flash a proper debugger. The other problem is that it's Winbloze :razz: Does MSVC come with its own debugger?

[QUOTE=Dubslow;301082]The problem is the only one who's currently "fluent" in the code is the only one for whom it works :razz: If my debug build doesn't help, then maybe we'll see about getting flash a proper debugger. The other problem is that it's Winbloze :razz: Does MSVC come with its own debugger?[/QUOTE]

Grasshopper...

Jumps before he walks....

[QUOTE=chalsall;301086]Grasshopper...

Jumps before he walks....[/QUOTE]

I wouldn't be as much fun any other way :smile:

[QUOTE=Dubslow;301087]I wouldn't be as much fun any other way :smile:[/QUOTE]

Many wouldn't agree.

Do you understand why the code crashes?

[QUOTE=chalsall;301089]
Do you understand why the code crashes?[/QUOTE]

Do you? :unsure: