DISPLAY OPENFILE Issue

[David Dormier]

Well, if anyone's interested,...

I did find my problem(s) after commenting out lines of code and running the debugger to find the culprit(s); one was a bogus constant declaration and the other was a re-entrant variable defined as STATIC.

I'm definitely new to PB programming and pretty much believe everything I read in the Help files and forums. I'm "hacking" alot of example code together to provide a proof-of-concept design and needless to say my lack of detailed PB knowledge and a broad hack-job is what bit me. I still have more things to add, more concept proving to do, and probably a few more forum posts to make, but, I find it quite refreshing when compared to the over-glorified Commodore 64 BASIC Interpreter currently produced by MS.

I do hope the support group is open to suggestions, because I have a few things that I find a nuisance.

Thanks for everyone's help!

[Michael Mattias]

Hey, my request for "help file only" updates is already in, and has been for some time.

If you, too, want to have up-to-date, accurate and more comprehensive documentation at your "F1 fingertips" (not just on-line) , send those suggestions to [email protected]



MCM

[Gary Beene]

And, the IDE could easily have a menu item to check for, and download, the new Help file. Better yet, have it be a (optional) check on startup - just like many programs check for updates on startup.

One thing - if there is a Help file release - there MUST be a ChangeLog summarizing what has changed. Without a change log, a new Help file is good for future reference, but not for letting someone know what information they've already read (and are using) has been updated.

In gbSnippets, I have a "Daily Message" Help menu item. I put a regularly updated, simple text message online, saying whether the app, it's Help file, or snippet library updates are available - and summarizing the changes. This makes it's use entirely optional on the part of the user - for those who hate intrusive messages (however well-meaning) they are.

And yes, the forums are one vehicle to do this. But not everyone wants to go pop open a browser, especially when the information could be ready at hand in the IDE.

[Paul Squires]

You would think that it would be easy to make the help file changes and then at least publish the new version to the on-line version: http://www.powerbasic.com/support/help/pbwin/index.htm

[Michael Mattias]

>You can know it if you disassemble the code

I purchase licenses for high-level language compilers just so I can do that.

I would be remiss, however, if I didn't remind readers that because DISPLAY OPENFILE is proprietary, "how" it is implemented is subject to change at any time without notice.

Actually, I'm being kind of anal here for one reason: to impress upon any of the PBPTB who happen to be lurking that accuracy in documentation is important; and that it's still I think a wonderful idea to start offering "help file only" updates. Goodness knows there have been more than enough to make with the release of 9x.

Why should we have to wait for bug fixes to be thoroughly beta-tested and packaged into 'update patch files' simply to get corrections to the help file?


MCM

[Dave Biggs]

>I'm still getting a run-time error though,... Any thoughts?

Try addng #Debug Display On to the begining of your code.

#DEBUG DISPLAY ON enables error display mode within a compiled PowerBASIC program. In this mode, whenever an untrapped error occurs (without the benefit of ON ERROR GOTO, TRY/CATCH, etc.), program execution is suspended, and a descriptive message is displayed.

That can often help in these sorts of situations.

[José Roca]

All the flags used by DISPLAY OPENFILE have the same names and values than the ones used by GetOpenFileName with the only difference, in the name (the value is the same), of OFN_SHAREWARE/OFN_SHAREAWARE. If It's white and in a bottle, it must be milk.

.... but we don't know that for a fact.

You can know it if you disassemble the code.

[Michael Mattias]

>It obviously is a typo

Obviously? DISPLAY OPENFILE is a proprietary function; why wouldn't it be using proprietary equates?

It might be 'obvious' because '%OFN_SHAREAWARE' gets highlighted as a keyword in the IDE, but beyond that there is no reason to think it's not simply a compiler error and the function was DESIGNED to accept "OFN_SHAREWARE"

OR, it might be 'obvious' in the sense you or I or others who have been programming in Windows a while can "make a guess" that DISPLAY OPENFILE is some kind of wrapper function for the GetOpenFileName Windows' API function, with the flags member passed "as is" .... but we don't know that for a fact.

MCM

[Michael Mattias]

If you are new to Windows' programming using PowerBASIC, many times General Protection Fault errors occur not at the line where you think they did... in fact the actual error may have been made hundreds or thousands of statements ago.

Your statement, "It doesn't always occur the first or second try (sometimes it does), but, usually after the third, fourth, or more tries" suggests the problem IS elsewhere, as I will bet you are doing "something" after that first, second or third try.

The code you posted is simply insufficient for anyone to tell where your problem really is.

I ran it as written (inserted into the function shown) and it worked just fine.

MCM

[David Dormier]

Thanks for constant correction. %OFN_SHAREAWARE works.

I'm still getting a run-time error though,...

Any thoughts? I'm running Vista and PBForms to help with the GUI.

[José Roca]

It obviously is a typo. The correct name if OFN_SHAREAWARE.

[Michael Mattias]

Oops, sorry; my error. I did not RTFM where it clearly says...

%OFN_SHAREWARE
If the dialog fails because of a network sharing violation, the error is ignored and the selected filename is returned.

.. on the help page for DISPLAY OPENFILE.

Well, then, the documentation is lying. You will have to contact [email protected] to ask them why the software does not work as documented.

[Michael Mattias]

I made you example COMPILABLE using ...

FUNCTION TestDisplayOpenFile () AS LONG
  LOCAL File2Use$, start$,folder$
  folder$ = CURDIR$
  start$ = "*.scn"

   DISPLAY OPENFILE ,,, "Open Scenario File", folder$, _
       CHR$("Scenario Files", 0, "*.scn", 0,"All Files",0,"*.*",0),start$, "SCN", _
      %OFN_FILEMUSTEXIST OR %OFN_HIDEREADONLY OR %OFN_LONGNAMES OR _
      %OFN_EXPLORER TO File2Use$
      
END FUNCTION

.. and called it from PBMain with no problems.

Also,

I've also found the compiler gives me an undefined error when using "%OFN_SHAREWARE"

No, it give an "undefined equate" error.

That's because either you have not typed...

%OFN_SHAREWARE  =  somenumber

.. somewhere, or maybe because you DID type "%OFN_SHAREWARE" when you meant to type "%OFN_SHAREAWARE"

MCM

[David Dormier]

I'm getting a runtime stack dump for illegal address when using the "DISPLAY OPENFILE" where a user selects an "Open" option from a menu in my program. It doesn't always occur the first or second try (sometimes it does), but, usually after the third, fourth, or more tries. I'm thinking it's in this call because my program doesn't crash otherwise and makes it here during debug sessions.

I've also found the compiler gives me an undefined error when using "%OFN_SHAREWARE"

Here's my test code section:
LOCAL File2Use$, start$,folder$
folder$ = CURDIR$
start$ = "*.scn"

DISPLAY OPENFILE ,,, "Open Scenario File", folder$, _
CHR$("Scenario Files", 0, "*.scn", 0,"All Files",0,"*.*",0),start$, "SCN", _
%OFN_FILEMUSTEXIST OR %OFN_HIDEREADONLY OR %OFN_LONGNAMES OR _
%OFN_EXPLORER TO File2Use$

Any ideas? If no one else is having this problem (either with multiple executions or the undefined constant), would an uninstall/re-install have any effect? Where would I look for compiler updates/patches?

Thanks!