Announcement

Collapse
No announcement yet.

GetOpenFileName dialogue not visible

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

  • GetOpenFileName dialogue not visible

    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


    Code:
       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
    

  • #2
    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
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      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
      Code:
         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)       '

      Comment


      • #4
        > 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
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          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

          Comment


          • #6
            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?)
            Fred
            "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

            Comment


            • #7
              >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:
              Code:
                ' 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 ..
              Code:
              #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
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                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

                Comment


                • #9
                  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

                  Comment


                  • #10
                    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)
                    Engineer's Motto: If it aint broke take it apart and fix it

                    "If at 1st you don't succeed... call it version 1.0"

                    "Half of Programming is coding"....."The other 90% is DEBUGGING"

                    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                    Comment


                    • #11
                      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
                      kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                      Comment


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

                        Comment


                        • #13
                          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

                          Comment


                          • #14
                            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...
                            Code:
                            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.

                            Code:
                            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
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              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

                              Comment


                              • #16
                                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?
                                sigpic
                                Mobile Solutions
                                Sys Analyst and Development

                                Comment


                                • #17
                                  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!"

                                  Comment


                                  • #18
                                    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 :top:
                                    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.

                                    Engineer's Motto: If it aint broke take it apart and fix it

                                    "If at 1st you don't succeed... call it version 1.0"

                                    "Half of Programming is coding"....."The other 90% is DEBUGGING"

                                    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                                    Comment


                                    • #19
                                      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
                                      Last edited by Michael Mattias; 26 Jan 2008, 09:28 AM.
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        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

                                        Comment

                                        Working...
                                        X