GetOpenFileName dialogue not visible

[George Deluca]

I've got a problem with one user of a program of mine. Nobody else has reported it and I can't duplicate it. Here's what he's reporting.

The program issues a GetOpenFileName request to get user input of a file name. This is working correctly for me and seemingly for other users.

On his system the Common dialogue box does not appear at all. If he minimizes the main app and restores it the box will appear.

I'm not aware of any obvious flags etc. which may affect this action in the dialogue request.

The program is pretty basic PBWin 8.01, the code is pretty standard.

Anyone have thoughts?
George

[FONT="Courier New"]   IF Cmd = "" THEN                                ' If something left, assume a FileName
      ofnFileName ="AllFiles"                      ' Setup for Common Dialog call
      ofnInitDir = FileDir                         '
      ofnFilter = "All Files (*.*)" + CHR$(0) + "*.*" + CHR$(0) + CHR$(0)
      ofnDefExt = "txt"                            '
      ofnTitleName = "Select Filename to be Copied"'
      DoingMsg = %True                             ' Tell KB hook to ignore for a while
      IF GetOpenFilename(ofn) = %False THEN        '
         DoingMsg = %False                         ' Tell KB hook to restart
         CALL scError(%eFail, "File Selection Cancelled") ' No selection?   Bail out
         pCommand = Blanks                         '
         EXIT SUB                                  '
      ELSE                                         '
         DoingMsg = %False                         ' Tell KB hook to restart
         Cmd = TRIM$(ofnFileName)                  ' Get the filename
      END IF                                       '
   END IF                                          ' Non-blank Cmd, assume a FileName
[/FONT]

[Michael Mattias]

No OFN.lStructSize might be causing some problems. For that matter, I can't tell you set ANY members of the OFN UDT variable used in the GetOpenFileName call.

MCM

[George Deluca]

Hi Michael
Sorry I didn't paste it in. All the 'stock' fields of the OFN UDT are completed in the basic program initialization. I'll paste it in below.The Open Dialogue Does appear correctly for me and for all (no other reported problems) users. I just can't think why its failing for this one user.
George

   ofn.lStructSize = SIZEOF(ofn)                   ' Complete a Default OutPutFileName area
   ofn.hWndOwner = hWnd                            '
   ofn.hInstance = %NULL                           '
   ofn.lpstrFilter = VARPTR(ofnFilter)             '
   ofn.lpstrCustomFilter = %NULL                   '
   ofn.nMaxCustFilter = 0                          '
   ofn.nFilterIndex = 0                            '
   ofn.lpstrFile = %NULL                           '
   ofn.nMaxFile = %MAX_PATH                        '
   ofn.lpstrFileTitle = %NULL                      '
   ofn.nMaxFileTitle = 0                           '
   ofn.lpstrInitialDir = VARPTR(ofnInitDir)        '
   ofn.lpstrTitle = VARPTR(ofnTitleName)           '
   ofn.Flags = %OFN_HIDEREADONLY                   '
   ofn.nFileOffset = 0                             '
   ofn.nFileExtension = 0                          '
   ofn.lpstrDefExt = VARPTR(ofnDefExt)             '
   ofn.lCustData = 0                               '
   ofn.lpfnHook = %NULL                            '
   ofn.lpTemplateName = %NULL                      '
   ofn.hWndOwner = hWnd                            '
   ofn.lpstrFile = VARPTR(ofnFileName)             '
   ofn.lpstrFileTitle = VARPTR(ofnTitleName)       '

[Michael Mattias]

> just can't think why its failing for this one user.

It may be data dependent. I had one of these just yesterday.

In the ShFileOperation call, the pfrom member of the SHFILEOP structure must be double-null terminated, even though the string is ANSI, not Unicode.

However, if the data type is ASCIIZ and you move a string literal to that data which previously held a longer string, the resulting variable is now only single-null terminated. You have to manually RESET the variable before reassigning a new value. (And let me tell you, it was a DOG to figure out this problem).

Is it possible this only occurs to your user on the SECOND or subsequent call to the function? If so, can he change the results by browsing somewhere else on the first browse?

Too bad you still have not provided enough code to look for an error we could find here. (Data definitions and scope required).

But just off the top of my head...

Is GetOpenFileName call failiing? If so, use CommDlgExtendeError function to learn why. This is why these error-reporting functions exist.

MCM

[George Deluca]

Thanks for your thoughts Michael

Is it possible this only occurs to your user on the SECOND or subsequent call to the function? If so, can he change the results by browsing somewhere else on the first browse?

It's first time, user basically starts the program and does the equivalent of File/Open but receives no dialogue box.

Too bad you still have not provided enough code to look for an error we could find here. (Data definitions and scope required).

The ofn structure is defined globally, setup once by the init code I posted and then completed just before the API call itself.

Is GetOpenFileName call failiing? If so, use CommDlgExtendeError function to learn why. This is why these error-reporting functions exist.

This is my problem, I cannot get it to fail myself. If an error were occuring the code simply treats all errors as a User Cancel type and the user is NOT seeing a message to this effect.
I really think this is a case where the Open Dialogue is opening BEHIND the main window, I've asked the user to check this (he says it's not) but he does say a Minimize/Restore will pop up the Dialogue -- very suspicious to me.

George

[Fred Harris]

Sorry I don't have much to add George, but I tend to agree with you about the Z order issue. Could possibly be, I suppose. I believe SetWindowPos() function can be used to change the Z order of windows, but you need a hWnd of the window you wish to change the Z order for. Not sure I ever needed a hWnd for a common dialog box? Anyone know how to get this? (or even if its worthwhile to persue it?)

[Michael Mattias]

>This is my problem, I cannot get it to fail myself

???

So add a prompt (MSGBOX) (and of course the CommDlgExtendedError message), recompile and let the user get it to fail and report the error message to you?

I'd bet all my users would be happy to do this if it holds out the promise of getting it fixed!


MCM

FWIW, from my "GetOpenFileName" standard wrapper function:

  ' call the API
  SELECT CASE WhichSub
     CASE %SUB_INPUT_FILE
          Stat = GetOpenFileName (OFN(WhichSub))
     CASE %SUB_OUTPUT_FILE
        Stat = GetSaveFileName (OFN(WhichSub))
  END SELECT

  IF ISTRUE (Stat) THEN
     W                    = SPACE$(OFN(WhichSub).NMaxFile)
     pFullName            = OFN(WhichSUb).LpStrFile
     W                    = @pFullName
     W                    = TRIM$(W, ANY CHR$(0, &h20))
     ' set the initial search dir for the next time thru to equal this one
     SearchDir (WhichSub) = LEFT$(W, INSTR(-1, W, "\"))
     ' null out the file name for next call to provide consistent search behavior across 9x, NT and 2K:
     FileTitle(WhichSub)  = ""
     '
     IF ISTRUE AllowReadOnly THEN   ' parameter passed, non-zero, input file
          ReadOnly = (Ofn(whichSub).Flags AND %OFN_READONLY) = %OFN_READONLY  ' set to whatever was chosen
         ' MSGBOX "Readonly=" & STR$( (Ofn(whichSub).Flags AND %OFN_READONLY) = %OFN_READONLY)
     END IF
     FUNCTION = W
  ELSE
     LOCAL eCD AS DWORD
     eCD                  = CommDlgExtendedError
     IF ECD <> 0 THEN
        MSGBOX "GetOpen/SaveFileName failed on error#" & STR$(eCD), %MB_APPLMODAL OR %MB_ICONINFORMATION, "Yikes!!!
     END IF
     FUNCTION             = ""
  END IF

You can use formatMessage on this if you want for error text as in ..

#IF NOT %DEF (%SYSEMT_INC)
  %SYSEMT_INC  = 1
FUNCTION SystemErrorMessageText (BYVAL ECode AS LONG) AS STRING
  LOCAL Buffer AS ASCIIZ * 255
  FormatMessage %FORMAT_MESSAGE_FROM_SYSTEM, BYVAL %NULL, ECode, %NULL, buffer, SIZEOF(buffer), BYVAL %NULL
  FUNCTION = FORMAT$(ECode, "##### ") & Buffer
END FUNCTION

#ENDIF

[George Deluca]

Thanks Michael
The user isn't too swift, but I'm sure they can handle this. I just hope its not some Z-order problem since that won't show up as an error. i.e. if the box is just 'hidden' somewhere, Windows probably doesn't see any error happening.

George

[George Deluca]

Well, displaying errors returned by GetOpenFilename doesn't show anything since it never returns from the API call. Obviously windows thinks the Dialogue is on the screen, the user sees nothing, and everybody's just waiting.

The user says a Minimize/Restore pops up the box so I've asked him to do a file selection and return to the program and then do another function (like file save) to get another Dialogue box and see if THAT one appears.

George

[Cliff Nichols]

I saw this a year or 2 ago, (or more to the point, a partially painted "OpenFileDialog"), but can not remember the true fix, but if you throw in a sleep of 100, does the problem go away?

(I know sleep should only affect the current thread, but worth a shot just to see)

[Kev Peel]

Analyse the directory and file name for invalid characters. If you pass either to the file open/save common dialogs they will fail to show at all.
These problems crop up occasionally when I create a file name from other data, such as text entered by the user.

Invalid characters for a directory: ":*?<>|" + $DQ
Invalid characters for a file name: "\/:*?<>|" + $DQ

Replace Any ":*?<>|" + $Dq With "_______" In szRetPath

[Mike Montgomery]

This may be totally off target, but is the window that calls the dialog a modal form?

[George Deluca]

Thanks for the feedback.

Cliff > I'm confused (my normal state). Where would a SLEEP go? After the API call (wouldn't be issued, we never come back)? Before?

Kev > The directory is either a null string (1st time user) or the last used directory from a previous execution, not directly from user input. I will however ask him to look at what is actually there (in the Registry)

Mike > The dialogue is Modal, created without a parent in the DIALOGUE NEW request. Thinking??

George

[Michael Mattias]

Kev > The directory is either a null string (1st time user) ...

This could be a problem.

Generally when Windows wants "lpString" ... which would be VARPTR(Asciiz variable) in PB-speak, it wants BYVAL %NULL when the string is null, not the address of a null string.

I use this macro in these situations...

MACRO bvaz(asciizString) = BYVAL IIF(lstrlen(asciizString), VARPTR(AsCIIZString), %NULL)

Which supplies either "BYVAL NULL" or "BYVAL VARPTR(asciizString)" depending if the string has a length.

You can use the same kind of thing when you are assigning those values in the OpenFileName Structure...e.g.

ofn.lpstrInitialDir = VARPTR(ofnInitDir)
==>
ofn.lpstrInitialDir = IIF&(LstrLen(ofnInitDir), VARPTR(ofnInitDir), %NULL)

(do for all the members of OFN which want a string address)

MCM

[George Deluca]

Well, I've seen the Registry key now, the InitDir string isn't null, but a valid user dir (by it's look). It did have a directory level with an embedded period in it, so I tested that little quirk myself, and no problem.

Michael, I like your macro for the pointer. Its something I don't do enough of - use macros.

The user hasn't yet tried an install/test on another system yet so I don't know whether there's something unique/stupid about the current one. If it does work on his home system (its failing at work) then I really don't know how to pin this down.

George

[Roger Garstang]

Is this something like an XP vs. Win9x system? What OS is he using that fails/works? I know there are some differences in behavior for Modal/Topmost. Also, are there any other applications running that could be stealing focus...maybe even mouse options that move to default buttons or set focus to where the mouse hovers, etc?

[George Deluca]

Status Update for anyone following this thread.

The user having this problem has now seemingly gone AWOL and hasn't communicated at all for several days. I'm hoping this isn't a case of the problem just 'going away' or that they've found the problem and are embarrassed to say "Duh!"

[Cliff Nichols]

Or more like days, months, years after you long gave up, they call again in a "Hurry, put out the FIRE" attitude and its your fault.

Then you have to start allllll over from where you may be sooooo close to the solution now (thats IF the problem even exists)

Not to mention the old curse....It will happen when you are too busy researching other "UnKnown" problems, with not enough information to formulate an idea

George, I have to applaud you for updating us
All too often a question asked either goes unanswered due to "it went away" or just dropped.....
Its nice to see someone post that a question is dropped due to circumstances out of your control, and others are not wasting time answering what may have never been a problem in the first place.

[Michael Mattias]

Or more like days, months, years after you long gave up, they call again in a "Hurry, put out the FIRE" attitude and its your fault.

Excuse me, but is IS your fault!

You need to follow up and get the user to confirm either the problem still exists or it doesn't.

No, not here in an online forum, but certainly in any kind of regular partnership between a user and a support provider.


MCM

[George Deluca]

Michael,

I have followed up asking for status. As I said the user has gone AWOL and has simply not answered any emails. Unlike the initial problem period where we passed several messages a day back and forth.

It just p*sses you off when you have a good dialogue going on with a user to try and track a problem down, and then suddenly --- Nothing!

Makes you wonder why they even reported it.

George