Announcement

Collapse
No announcement yet.

Display Openfile issue

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

  • Michael Mattias
    replied
    The confirmation dialog is technically undocumented behaviour but it is standard Windows file dialog behaviour
    Perhaps we both need to read more carefully.

    The confirmation dialog is not "technically" undocumented, it's undocumented.

    And so what if a different function - the Windows' function - behaves differently? The Windows' function is not being used here.

    Leave a comment:


  • Jeff Blakeney
    replied
    Originally posted by Michael Mattias View Post
    > the observed behaviour is that there is a pop up confirmation dialog....

    No, the observed behaviour is that there is an undocumented pop up confirmation dialog ....
    Michael, you need to read messages a little more carefully. You just said the same thing I did. Here is the entire sentence I wrote that you quoted part of above (emphasis added):

    Originally posted by Jeff Blakeney View Post
    The only thing I could possibly see here is that when using this style, the observed behaviour is that there is a pop up confirmation dialog asking if the user would like to create the file because it doesn't exist and the documentation makes no mention of that being able to happen.
    The confirmation dialog is technically undocumented behaviour but it is standard Windows file dialog behaviour.

    Leave a comment:


  • Michael Mattias
    replied
    > the observed behaviour is that there is a pop up confirmation dialog....

    No, the observed behaviour is that there is an undocumented pop up confirmation dialog ....

    Leave a comment:


  • Jeff Blakeney
    replied
    Originally posted by Michael Mattias View Post
    But even if we did, it does not excuse the fact the observed behavior does not match the documented behavior.
    Let's see, the observed behaviour in this case is using %OFN_CREATEPROMPT with DISPLAY OPENFILE does not create a new, empty file. The documentation says this about the %OFN_CREATEPROMPT style:

    %OFN_CREATEPROMPT
    The user may specify a file which does not exist.
    Where is the observed behaviour not matching the documented behaviour? The only thing I could possibly see here is that when using this style, the observed behaviour is that there is a pop up confirmation dialog asking if the user would like to create the file because it doesn't exist and the documentation makes no mention of that being able to happen. Nowhere does the documentation say it will or will not create a new, empty file for you.

    I would agree that there should be more in the documentation to explain what happens when using this style but I do not see a conflict between observation and documentation here.

    Leave a comment:


  • Michael Mattias
    replied
    That's wrong. The way that the style in question affects the execution of the function is determined by the way that the underlying API function handles that style
    I guess we have different views on this subject.

    My view:

    HOW PowerBASIC Inc chooses to implement the DISPLAY OPENFILE statement is up to PowerBASIC Inc. However, PowerBASIC Inc remains one hundred percent responsible for the documentation and behavior of the DISPLAY OPENFILE statement.

    especially when you know that for the most part they are 'wrappers' for API functions
    ...
    The forerunner to 'Display Openfile' was the wrapper 'OpenFileDialog' ...
    And you know these things how?

    In this particular case your guess would be my guess. I think it is a good guess, but it is only a guess.

    Perhaps you have access to PowerBASIC's internal design documentation? News Flash: The rest of us don't.

    But even if we did, it does not excuse the fact the observed behavior does not match the documented behavior.

    MCM

    Leave a comment:


  • Dave Biggs
    replied
    >What's important is,...

    Trying to remember that these are Peer Support Forums and (except for threads with the title "You Talk... PowerBASIC Listens!" ?) their purpose is not to provide a soap box from which to harangue PowerBASIC's staff.

    >The bad news is, the problem is definitely in the execution of the DISPLAY OPENFILE function, and since that is a PB proprietary function, they are the only ones who can fix it... meaning A) you have to file a bug report and B) If you want your program to work now, you will have to find a workaround

    That's wrong. The way that the style in question affects the execution of the function is determined by the way that the underlying API function handles that style.

    Casting fear into new users by banging on about how 'Proprietary' PB's various built-in functions are is not helpful - especially when you know that for the most part they are 'wrappers' for API functions and are therefore bound by the foibles of those Windows Functions.

    The forerunner to 'Display Openfile' was the wrapper 'OpenFileDialog' which can be examined in detail by viewing the functions & declarations in ComDlg32.inc. This is where it's connection to the API GetOpenFileNameA() function can be seen
    The innerworkings of Display Openfile are not accessible for examination as it is now 'Built-in' to PBWin but that's no reason to expect that PB have suddenly re-invented the Windows OS !

    Leave a comment:


  • colin glenn
    replied
    I've always viewed %OFN_CREATEPROMPT as the "boolean opposite" to %OFN_FILEMUSTEXIST

    And I've never read the documents as to where it implies that the OS, or in this case, PB's wrapper, would actually create an empty file with that name.

    And as to using it with the OpenFile dialog, well, what if your application is one which deals with database's, and the user elects to create a new database instead of opening an old one. The prompt function from the dialog is a bonus gravy which saves you the effort of checking that the file exists, and if not, prompting the user "Are you sure?". Of course they're sure when you get back the filename, they've already agreed to it. All you have to do with your code is ensure that your parameter checking of the return includes the possibility of handling a new file instead of opening an existing file.

    Leave a comment:


  • Michael Mattias
    replied
    >keep bugging support at PB

    Curious choice of gerunds, but that's not important.

    What is important is, I believe assisting customers with the use of PowerBASIC products is why anyone who works in "PB Support" draws a paycheck.

    Leave a comment:


  • Jeff Blakeney
    replied
    Originally posted by Michael Mattias View Post
    It's time for the phonetic spelling of "assume," methinks.
    I kind of figured something that that would be coming. I think it was Benny Hill that first showed me the word assume split into 3, 1 and 2 letter words.

    Better still, it's probably safe for YOU to make that assumption, since you have been programming since at least 2003.
    Take another 22 years off that and you'll know what year I started programming.

    January of 2003 is when I joined this forum. I had been working full time for my brother for at least six months at that point helping him develop software for the deregulated electricity market in Ontario. About three months later the government basically reregulated electricity so I ended up losing my job. This is why I now work on a line in a factory.

    However, I'd never even hint at that to anyone who may have just opened his new box containing his "PowerBASIC for Windows" compiler!

    Render unto Microsoft that which is Microsoft's; render unto PowerBASIC that which is PowerBASIC's.
    The PB documentation could definitely be improved and a text for beginner's on programming with PB would help even more. However, at present, I'd rather point people to other possible places to find answers to problems they are having rather than telling them to keep bugging support at PB. This is why I've also been testing code and suggesting work arounds for problems as well. If I can't program full time, I can at least keep my skills sharpened by helping others.

    Leave a comment:


  • Michael Mattias
    replied
    >I think it is a pretty safe assumption that we can use either help.

    It's time for the phonetic spelling of "assume," methinks.

    Better still, it's probably safe for YOU to make that assumption, since you have been programming since at least 2003.

    However, I'd never even hint at that to anyone who may have just opened his new box containing his "PowerBASIC for Windows" compiler!

    Render unto Microsoft that which is Microsoft's; render unto PowerBASIC that which is PowerBASIC's.


    MCM

    Leave a comment:


  • Larry Burford
    replied
    Thanks guys, I appreciate the help. Despite the occasional (ahem) aggravation of something like this, it really is fun. I'll be monitoring this thread for a while longer, so if you or anyone else comes up with more information, opinions, please fire away.
    Last edited by Larry Burford; 17 Oct 2009, 11:51 AM.

    Leave a comment:


  • Jeff Blakeney
    replied
    Originally posted by Michael Mattias View Post
    > From the SDK docs for the GetOpenFileName API function..

    ... Which has absolutely ZERO bearing on Mr. Burford's problem, because he is not using the WIndows 'GetOpenFileName' function, he is using the PowerBASIC 'DISPLAY OPENFILE' function.
    All the PB documentation for OFN_CREATEPROMPT says is:

    %OFN_CREATEPROMPT
    The user may specify a file which does not exist.
    Which says nothing about a message box popping up asking the user if they want to create the file, nor does it say anything about it creating a file that doesn't exist for you. Seeing as DISPLAY OPENFILE and GetOpenFileName perform the same function, use the same parameters, use the same styles and look and act exactly the same, I think it is a pretty safe assumption that we can use either help.

    DDT has been advertised as a simpler way to do Windows API programming after all and in many cases, it is simply making it so that you don't need to declaure a UDT, fill that UDT and pass that UDT to the appropriate API call.

    Leave a comment:


  • Jeff Blakeney
    replied
    Looking at both the PB and Win32 help files, it seems to me that when using the OFN_CREATEPROMPT style, if you specify a file that doesn't exist and hit the OK button, the file dialog will ask the user if they want to create the file. If they say no, then they go back to the file dialog, if they say yes, then the file dialog is closed and that new name is returned from the file dialog function. Nowhere does it say that the file dialog routine will actually create the file for you. In fact, here is exactly what the Win32 API help file I use says:

    OFN_CREATEPROMPT
    If the user specifies a file that does not exist, this flag causes the dialog box to prompt the user for permission to create the file. If the user chooses to create the file, the dialog box closes and the function returns the specified name; otherwise, the dialog box remains open.
    To me, that means that if you use the OFN_CREATEPROMPT style, then you need to check to see if the file exists before trying to use it and create it if it doesn't exist. If you are not using the OFN_PATHMUSTEXIST style, then you also need to make sure all the directories in the path exist as well and create them as well if they don't exist.

    Added: Wow! Five posts added while I was composing this reply. Talk about speedy responses.

    Leave a comment:


  • Michael Mattias
    replied
    > From the SDK docs for the GetOpenFileName API function..

    ... Which has absolutely ZERO bearing on Mr. Burford's problem, because he is not using the WIndows 'GetOpenFileName' function, he is using the PowerBASIC 'DISPLAY OPENFILE' function.

    (Although he may be shortly be using GetOpenFilename, see suggested workaround, in which case your cite of the Windows' documentation will no doubt be quite useful).

    MCM

    Leave a comment:


  • Larry Burford
    replied
    OK, see what you mean. Despite the wording of the help file text and the prompt text, in actual fact the claim is not made that the new file will actually BE created. (Depends on what the meaning of the word "is" is ... ?)

    I know how to create a new file in code.

    Hmmm. Programmers should never be allowed to write help file text. But, I suppose that is a topic for the Cafe ...
    Last edited by Larry Burford; 17 Oct 2009, 11:40 AM.

    Leave a comment:


  • Michael Mattias
    replied
    >the msgbox message comes after the "create?" message

    Well, then, we have good news and bad news...

    The good news is, you have successfully isolated the source of the problem....which is often ninety percent of the way to a solution.

    The bad news is, the problem is definitely in the execution of the DISPLAY OPENFILE function, and since that is a PB proprietary function, they are the only ones who can fix it... meaning A) you have to file a bug report and B) If you want your program to work now, you will have to find a workaround.

    If you are accepting suggestions for a workaround.....
    Code:
    DISPLAY OPENFILE ......           TO filevar, Countvar    DO NOT USE OFN_CREATEPROMPT
       IF Countvar > 0 THEN 
            do something because user selected at least one file 
            IF DIR$(Filevar) = "" THEN 
                 do whatever you do when the user has specified a currently nonexistent file
            ELSE
                do whatever you would have done had the OFN_CREATEPROMPT option
                worked as advertised
           END IF 
       ELSE
        ' user canceled and did not select a file 
         ....
      END IF
    Yes, you CAN do this without forcing a loop to try again (if that's what you want to do, insufficient code shown), but to do this you will need to eschew DISPLAY OPENFILE and use the Windows "GetOpenFileName" common dialog with a hook procedure.

    But it's your lucky day if you want to that because you can pretty much 'copy and paste' this demo:

    Explorer-Style hook Procedures for OpenFileDialog and SaveFileDialog 3-31-07

    Or, you could write a "DISPLAY OPENFILE" function of your own from scratch.

    MCM

    Leave a comment:


  • Larry Burford
    replied
    FYI,

    If I answer No to the "create file ? " prompt, I am returned to the OpenFile dialog.

    If I cancel the OpenFile dialog, fileName comes back empty, and countVar comes back zero. (And no file is created ...



    All of this seems like expected behavior.

    Leave a comment:


  • Dave Biggs
    replied
    From the SDK docs for the GetOpenFileName API function..

    OFN_CREATEPROMPT
    If the user specifies a file that does not exist, this flag causes the dialog box to prompt the user for permission to create the file. If the user chooses to create the file, the dialog box closes and the function returns the specified name; otherwise, the dialog box remains open. If you use this flag with the OFN_ALLOWMULTISELECT flag, the dialog box allows the user to specify only one nonexistent file.

    Windows doesn't actually create the file. If you are going to use that flag you'll have to deal with the possible return of a non-existant file name in you code... somehow
    Last edited by Dave Biggs; 17 Oct 2009, 11:28 AM. Reason: Additional text from SDK

    Leave a comment:


  • Larry Burford
    replied
    the msgbox message comes after the "create?" message

    countVar = 1

    Leave a comment:


  • Larry Burford
    replied
    Hmmm. There are no files to select (with the specified extension) in the particular folder I am using for this test. However, I presume that if I enter a name in the file name box and answer Yes to the "... create it ? " prompt, then varCnt will be set to "1".

    I'll let you know ...

    Leave a comment:

Working...
X