Display Openfile issue

[Larry Burford]

I'm using the new Display Openfile statement for the first time, and having a problem.

display openfile hParent, , , "Title", "", filter, "", ".whatever", %OFN_CREATEPROMPT to fileName

All seems right unless I enter a file name that is not in the selected path. I get the msg "file not found, create it?" and answer yes.

The string fileName is populated with the path and new file name, but the new file is not created.

Since no one else is asking about this, I presume I am overlooking something about the proper use of this statement?

WXP, SP3, AMD 3200+, PB 9.01.0100

[Michael Mattias]

I would say that is a problem with the DISPLAY OPENFILE function, since per doc...

%OFN_CREATEPROMPT
The user may specify a file which does not exist.

... the user has yet to select a file by clicking "OK" in the window ...
Or do you get this message on return? (insufficient code posted)

.... OR ... if you don't get this message until DISPLAY OPENFILE returns, the doc does not say you will be prompted for permission.

In a larger picture.. if the user MAY specify a file to 'open' which does not exist ( a concept tough for me to understand), perhaps DISPLAY SAVEFILE would be a better choice of functions to use?

(PowerBASIC's documented behavior when the OFN_CREATEPROMPT flag is used varies from the documentation for the Microsoft use of same, so clearly you will have to get an explanation of what the PowerBASIC use's behavior is supposed to be from PowerBASIC).

MCM

[Larry Burford]

The exact wording of the message I get is:

<file.ext>
This file does not exist.

CreateThis file?

Yes No



I'll try the SaveFile alternative, and let you know ...

[Larry Burford]

The savefile dialog behaves the same, with one exception: it does not give me the message asking if I want to create the missing file.

[Michael Mattias]

No, no you are missing my point.....

The relevant code in its entirety , with a suitable debugging display, should be something like

   DISPLAY OPENFILE ......           TO filevar, Countvar 
   MSGBOX "Returned from DISPLAY OPENFILE" 
   IF Countvar > 0 THEN 
        do something because user selected at least one file 
   ELSE
    ' user canceled and did not select a file 
     ....
  END IF

Do you get that 'OK to create' message before or after the message "Returned from DISPLAY OPENFILE?"

[Larry Burford]

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

[Larry Burford]

the msgbox message comes after the "create?" message

countVar = 1

[Dave Biggs]

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

[Larry Burford]

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.

[Michael Mattias]

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

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

[Larry Burford]

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

[Michael Mattias]

> 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

[Jeff Blakeney]

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.

[Jeff Blakeney]

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

[Larry Burford]

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.

[Michael Mattias]

>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

[Jeff Blakeney]

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.

[Michael Mattias]

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

[colin glenn]

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.

[Dave Biggs]

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