> Makes you wonder why they even reported it.
"Why?"
"Because."
MCM
Announcement
Collapse
No announcement yet.
GetOpenFileName dialogue not visible
Collapse
X
-
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
Leave a comment:
-
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.
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.
MCMLast edited by Michael Mattias; 26 Jan 2008, 08:28 AM.
Leave a comment:
-
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.
Leave a comment:
-
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!"
Leave a comment:
-
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?
Leave a comment:
-
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
Leave a comment:
-
Kev > The directory is either a null string (1st time user) ...
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)
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)
MCM
Leave a comment:
-
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
Leave a comment:
-
This may be totally off target, but is the window that calls the dialog a modal form?
Leave a comment:
-
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
Leave a comment:
-
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)
Leave a comment:
-
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
Leave a comment:
-
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
Leave a comment:
-
>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
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
Leave a comment:
-
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?)
Leave a comment:
-
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?
Too bad you still have not provided enough code to look for an error we could find here. (Data definitions and scope required).
Is GetOpenFileName call failiing? If so, use CommDlgExtendeError function to learn why. This is why these error-reporting functions exist.
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
Leave a comment:
-
> 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
Leave a comment:
-
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) '
Leave a comment:
-
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
Leave a comment:
Leave a comment: