Announcement

Collapse
No announcement yet.

Issue with OpenFi99l8e

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

  • Issue with OpenFi99l8e

    Hello all,
    I am seeing an issue with OpenFileDialog() that I can't figure out how to resolve. When i call the dialog with the last file selected as the default file name, the file name does not fully show in the selection box. It is highlighted and shows about half the name of the file. If i click outside the name box in the dialog, then back into the name box, it shows the whole name. For example the dialog below was called with "suggested file really long name.dat" as the default file. It only shows "y long name.dat" as the highlighted text in the File Name box. I'm running Windows 10 on a Lenovo P15s laptop (Intel I7).

    Click image for larger version

Name:	name cut off openfiledialog().jpg
Views:	191
Size:	70.3 KB
ID:	816620

    Here's the code:

    Code:
    #COMPILE EXE
    #DIM ALL
    #INCLUDE "WIN32API.INC"
    #INCLUDE "COMDLG32.INC"
    
    'use this to select multifiles
    '%OFN_ALLOWMULTISELECT OR %OFN_EXPLORER OR _
    ' %OFN_FILEMUSTEXIST OR %OFN_NODEREFERENCELINKS _
    '
    FUNCTION PBMAIN () AS LONG
    
    LOCAL sFilename AS STRING
    LOCAL sPath AS STRING
    LOCAL filefilter AS STRING
    
    sfilename = "suggested file really long name.dat"
    PRINT
    
    sPath = CURDIR$
    filefilter = "All Files (*.*)|*.*|Text Files (*.TXT, *.BAT)|*.TXT;*.BAT|"
    IF OpenFileDialog(BYVAL %HWND_DESKTOP, "Find File To Process", sFilename, sPath, filefilter, "test string", %OFN_EXPLORER OR %OFN_FILEMUSTEXIST OR %OFN_NODEREFERENCELINKS ) = 0 THEN
    'cancel hit
    PRINT "Cancel hit"
    END IF
    PRINT "returned file name = "; sFilename
    WAITKEY$
    
    
    
    END FUNCTION

  • #2
    You may just need an additional flag
    OFN_LONGNAMES0x00200000 For old-style dialog boxes, this flag causes the dialog box to use long file names. If this flag is not specified, or if the OFN_ALLOWMULTISELECT flag is also set, old-style dialog boxes use short file names (8.3 format) for file names with spaces. Explorer-style dialog boxes ignore this flag and always display long file names.
    I am not sure why you are getting this behavior when you are specifying the OFN_EXPLORER flag already, but it can't hurt to try it.

    And if you want a deluxe version of this PB-Created function, look here...


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

    Doc explaining all available flags : https://docs.microsoft.com/en-us/win...-openfilenamew

    MCM

    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      It's a problem with the WIndows OpenFileDialog and has been for quite a few years, it doesn't only happen with PB::

      For possible kludgy work arounds, see these and associated links.

      https://stackoverflow.com/questions/...ated-file-name

      https://social.msdn.microsoft.com/Fo...orum=vcgeneral

      Comment


      • #4
        It's worth noting that the same thing happens with OpenFileDialog with PBWin, but not with PBWIn's built in DISPLAY OPENFILE
        '
        Code:
        #COMPILE EXE
        #DIM ALL
        FUNCTION PBMAIN () AS LONG
            LOCAL sFilename AS STRING
            LOCAL sPath AS STRING
            LOCAL filefilter AS STRING
        
            sfilename = "suggested file really long name.dat"
            sPath = CURDIR$
            filefilter = "All Files (*.*)|*.*|Text Files (*.TXT, *.BAT)|*.TXT;*.BAT|"
        
            DISPLAY OPENFILE 0, ,, "Find File To Process", sPath, filefilter$, _
               sFilename, "",  %OFN_ENABLESIZING  OR %OFN_FILEMUSTEXIST OR %OFN_NODEREFERENCELINKS TO sFileName
        
            MSGBOX sFilename
        END FUNCTION
        '
        ]

        Comment


        • #5
          A problem is that the ComboBox there is "owned" by the Shell (if I remember correct), but is possible to install a global hook procedure and send a couple of keystrokes via it to fix problem (as suggested under one of the link Stuart posted). Not so "kludgy" Anyway - this works for me:
          '
          Code:
          #COMPILE EXE
          #DIM ALL
          
          #INCLUDE "WIN32API.INC"
          #INCLUDE "COMDLG32.INC"
          GLOBAL ghHook AS DWORD
          
          'use this to select multifiles
          '%OFN_ALLOWMULTISELECT OR %OFN_EXPLORER OR _
          ' %OFN_FILEMUSTEXIST OR %OFN_NODEREFERENCELINKS _
          '
          '============================================================================================
          FUNCTION PBMAIN () AS LONG
            LOCAL sFilename AS STRING
            LOCAL sPath AS STRING
            LOCAL filefilter AS STRING
          
            sfilename = "suggested file really long name.bat"
            PRINT
          
            sPath = CURDIR$
            filefilter = "All Files (*.*)|*.*|Text Files (*.TXT, *.BAT)|*.TXT;*.BAT|"
          
          
            ghHook = SetWindowsHookEx(%WH_CBT, CODEPTR(OfHookProc), _ 'set up a global hook for CmDialog
                                      GetModuleHandle(""), GetCurrentThreadId)
          
            IF OpenFileDialog(BYVAL %HWND_DESKTOP, "Find File To Process", sFilename, sPath, filefilter, "test string", _
                              %OFN_EXPLORER OR %OFN_FILEMUSTEXIST OR %OFN_NODEREFERENCELINKS ) = 0 THEN
                'cancel hit
                PRINT "Cancel hit"
            END IF
          
            IF ghHook THEN UnhookWindowsHookEx ghHook : ghHook = 0  ' unhook when done
          
          
            PRINT "returned file name = "; sFilename
            WAITKEY$
          
          END FUNCTION
          
          '============================================================================================
          FUNCTION OfHookProc(BYVAL nCode AS LONG, BYVAL wParam AS DWORD, BYVAL lParam AS LONG) AS LONG
            IF nCode = %HCBT_ACTIVATE THEN
                Keybd_Event %VK_HOME, 0, 0, 0    ' fix long file name problem (Press "Home" key)
                Keybd_Event %VK_HOME, 0, %KEYEVENTF_KEYUP, 0
          
                Keybd_Event %VK_CONTROL, 0, 0, 0 ' reselect file name (Press Ctrl+A)
                Keybd_Event %VK_A, 0, 0, 0
                Keybd_Event %VK_A, 0, %KEYEVENTF_KEYUP, 0
                Keybd_Event %VK_CONTROL, 0, %KEYEVENTF_KEYUP, 0
            END IF
            FUNCTION = CallNextHookEx(BYVAL ghHook, BYVAL nCode, BYVAL wParam, BYVAL lParam)
          END FUNCTION
          '

          Comment


          • #6
            Thank you all for the responses!
            Michael - i added your code to my library of tricks
            Stuart - thanks for the insight on the problem. Hard to imagine that something as basic as the open/save dialog would not work perfectly....
            Borje - thanks for the working example! Is it possible for you to write a keystroke program that will fix my errors as i type them so i don't have to debug any more programs? haha

            take care
            Larry

            Comment


            • #7
              And then frustration....

              I compile and run your example without any problems Borje. I insert the code exactly as in the example and it won't work in my program. I tried changing the includes for win32api.inc and COMDLG32.inc to specific locations. It works fine in the example, and mine displays like nothing has been modified.

              it appears that this statement within the FUNCTION OfHookProc() :

              IF nCode = %HCBT_ACTIVATE THEN....

              is never true in my program. I commented out this condition, and the dialog appears, the name is in the right position, but the HOME key is being hit continuously. I have to kill the program to get control of my laptop after that.

              any ideas?
              thanks
              Larry

              Comment


              • #8
                Strange. At least it seems like the hook works and OfHookProc is called, but it should be a %HCBT_ACTIVATE message there. I have seen some codes where CallNextHookEx is called before trapping %HCBT_ACTIVATE and then UnhookWindowsHookEx is done at end of it, like below, but don't know if that would help. Else, if not too huge code, maybe you can zip it up so I could have a look at it, or come up with an example that fails like you describe.
                '
                Code:
                FUNCTION OfHookProc(BYVAL nCode AS DWORD, BYVAL wParam AS DWORD, BYVAL lParam AS LONG) AS LONG
                  FUNCTION = CallNextHookEx(BYVAL ghHook, BYVAL nCode, BYVAL wParam, BYVAL lParam)
                  IF nCode = %HCBT_ACTIVATE THEN
                      Keybd_Event %VK_HOME, 0, 0, 0    ' fix long file name problem (Press "Home" key)
                      Keybd_Event %VK_HOME, 0, %KEYEVENTF_KEYUP, 0
                
                      Keybd_Event %VK_CONTROL, 0, 0, 0 ' reselect file name (Press Ctrl+A)
                      Keybd_Event %VK_A, 0, 0, 0
                      Keybd_Event %VK_A, 0, %KEYEVENTF_KEYUP, 0
                      Keybd_Event %VK_CONTROL, 0, %KEYEVENTF_KEYUP, 0
                      UnhookWindowsHookEx ghHook
                  END IF
                END FUNCTION
                '

                Comment


                • #9
                  HCBT_ACTIVATE fires when the system is about to activate a window. On my Win7 and Win10 systems, the keystrokes need to be delayed to give the Open Dialog a bit more time to be shown.

                  The following mod to Borje's hook code seems to work - (also shows a different 'kludgy' solution, from the second Stackoverflow link that Stuart posted ..
                  Code:
                  #COMPILE EXE
                  #DIM ALL
                  #INCLUDE "WIN32API.INC"
                  #INCLUDE "COMDLG32.INC"
                   
                  GLOBAL hHook AS Dword
                   
                  FUNCTION PBMAIN () AS LONG
                   LOCAL sFilename AS STRING
                   LOCAL sPath AS STRING
                   LOCAL filefilter AS STRING
                   
                    sfilename = "suggested file really long name.dat"
                      PRINT
                    sPath = CURDIR$
                    filefilter = "All Files (*.*)|*.*|Text Files (*.TXT, *.BAT)|*.TXT;*.BAT|"
                  
                     hhook = setwindowshookex(%WH_CBT, CODEPTR(HookProc), getmodulehandle(BYVAL 0&), getcurrentthreadid)
                    IF OpenFileDialog(BYVAL %HWND_DESKTOP, "Find File To Process", sFilename, sPath, filefilter, _
                     "test string", %OFN_EXPLORER OR %OFN_FILEMUSTEXIST OR %OFN_NODEREFERENCELINKS OR %OFN_LONGNAMES ) = 0 THEN 'cancel hit
                      PRINT "Cancel hit"
                    END IF
                     UnhookWindowsHookEx(hHook) : hHook = 0
                      PRINT "returned file name = " sFilename
                    WAITKEY$
                  END FUNCTION
                  '------------------/PBMAIN
                   
                  FUNCTION HookProc(BYVAL nCode AS LONG, BYVAL wParam AS LONG, BYVAL lParam AS LONG) AS LONG
                   FUNCTION = CallNextHookEx(BYVAL hHook, BYVAL nCode, BYVAL wParam, BYVAL lParam)
                    IF nCode < 0 THEN EXIT FUNCTION
                    IF nCode = %HCBT_ACTIVATE THEN
                      LOCAL hThread AS LONG
                       THREAD CREATE DelayPost(wParam) TO hThread
                       THREAD CLOSE hThread TO hThread : hThread = 0
                    END IF
                  END FUNCTION
                  '------------------/HookProc
                   
                  THREAD FUNCTION DelayPost(BYVAL hWnd AS LONG) AS LONG
                     SLEEP 300
                      PostMessage(hWnd, %WM_NEXTDLGCTL, 0, %FALSE)
                      PostMessage(hWnd, %WM_NEXTDLGCTL, 1, %FALSE)
                  END FUNCTION
                  '------------------/DelayPost
                  Rgds, Dave

                  Comment


                  • #10
                    Hi Dave, that code works in my program. I appreciate the time you and Bjore took to help me with this.

                    thanks!
                    Larry

                    Comment


                    • #11
                      Nice solution, Dave - thanks!

                      Comment

                      Working...
                      X