Open/Save Windows dialogs now repaired for both 32/64 bit versions.

[Petr]

For the program to function properly, it is important to keep writing the mask when calling GetSaveFileName. At the end, I added a small program to the opensave.bm file that filters the file extension in 64 bits (the dialog already correctly returns the extension selection number, but stubbornly refused to filter the mask. So I did so. I also made some adjustments in the opensave.bi file

I tested this program as it is in both 32 and 64 bit IDE and it works properly.


Repaired small bug (added condition to end to file opensave.bm)

SierraKen find next bug, if is file overwrited. This bug is repaired in version 3.

[bplus]

Thanks Petr, I was testing save, canceled and it returned ".jpg" should it return "", ie nothing?

[Petr]

Thank for report. Bug repaired, source reuploaded.

[SpriggsySpriggs]

@Petr your way of making it attach the extension at the end is the exact same way that I was doing it this afternoon but for some reason Ken's code wouldn't save the image even though the filename was correct. Good work. I'll update the Wiki with your code.

[SierraKen]

Petr, I found another bug. When the user Saves a picture as the same name of an existing picture, first it asks if you want to overwrite it, which is good, but then when it saves it, it saves with a second extension to it. For example, if you save over another one called picture.jpg, it will save the file as picture.jpg.jpg
So, I found a way around this in my own Paint Pixels 7 program by calculating the number of characters of nm$ with LEN and then reducing the characters from nm$ with RIGHT$. Below is what I made. Also, just so you know, your OPEN and SAVE dialogue has the exact same OFN commands which shouldn't be done. Because when you open a file, it has nothing to do with overwrite. So, I put in the same OFN commands as I did yesterday and it works fine. If you need help with my code, please ask. But THANK YOU for fixing the other Save problem I had, at least I don't need to add the .jpg anymore. I also used your idea and letting the user to my program save as JPG, PNG, or BMP. :))))
If you need help with my code below, please ask.  Oh also, there's a very slight minor bug as well, which I have no idea if it can be fixed, but when the user switches directories to open a picture file and looks on the JPG, PNG, BMP list for some reason it's adding a part of the _TITLE text after that on that same list. LOL

Code: QB64: [Select]

1. 'Saving Section
2. saving:
3. nm$ = GetSaveFileName("Save Image", ".\", "JPG Image (.jpg)|*.jpg|PNG Image (.png)|*.png|BMP Image (.bmp)|*.bmp", 1, OFN_OVERWRITEPROMPT + OFN_NOCHANGEDIR, _WINDOWHANDLE)
4. IF nm$ = "" THEN GOTO skipsave:
5. IF RIGHT$(nm$, 8) = ".jpg.jpg" OR RIGHT$(nm$, 8) = ".png.png" OR RIGHT$(nm$, 8) = ".bmp.bmp" THEN
6.     letters = LEN(nm$)
7.     nm$ = LEFT$(nm$, letters - 4)
8. END IF
9. _DELAY .25
10. Result = SaveImage(nm$, 0, 0, 0, _WIDTH(img), _HEIGHT(img)) 'first zero is your screen, second zero is X start, 3th zero is y start
11. _DELAY .25
12. nm$ = ""
13. skipsave:
14. dMode = 1
15. m = 1
16. RETURN
17.  
18. 'Loading Section
19. loading:
20. nm$ = GetOpenFileName$("Open Image", ".\", "JPG Image (.jpg)|*.jpg|PNG Image (.png)|*.png|BMP Image (.bmp)|*.bmp", 1, OFN_FILEMUSTEXIST + OFN_NOCHANGEDIR + OFN_READONLY, _WINDOWHANDLE)
21. IF nm$ = "" THEN GOTO skipopen:
22. CLS
23. l = 0
24. i& = _LOADIMAGE(nm$, 32)
25. SCREEN i&
26. s& = i&
27. i& = 0
28. screenx = _WIDTH
29. screeny = _HEIGHT
30. picture& = _NEWIMAGE(screenx, screeny, 32)
31. SCREEN s&
32. skipopen:
33. dMode = 1
34. m = 1
35. RETURN
36.  

[Petr]

Hi.
Thanks for report. First bug - overwriting under the same name without adding new extension if extension already exist solved in BM file (download version 3 for try). What you thing with OFN commands? I have none problems with adding part of _TITLE to opendialog windows here. Is not your _TITLE changed, when is open/save dialog run?

You still do the same error with using Steve library. Again, your row 10 in your source code is writed badly.

[SierraKen]

I just mean that OFN_OVERWRITEPROMPT is only for SAVE because it detects to see if you are saving to an existing file name. I added a couple more to my OPEN file area for different things that are only designated for OPEN. I learned about all of these in your OpenSave.bi file in the comments.

Thanks for fixing the bug Petr and telling me how to fix the _TITLE problem. I added SLEEP commands to the end of the SAVE and LOAD areas so that it wouldn't automatically go to the loop at the same time you are doing the Open or Save dialogs. People just have to select what they want to do before they start drawing again, no big deal. :) I'm about ready to post my newest update to the Paint Pixels 7 thread again. THANKS!

[Petr]

Hi SierraKen, I now had a very long break from regular programming. On warm days, I had to prioritize the necessary work around the house as well as things with my family. It's cold now and I'm coming back. Slowly, of course.

  I found one problem that can confuse programmers who will want to use this dialog when working with the mouse. I'm writing something here, and when calling the dialog to open the file, after returning back to the program, the mouse registry remained populated. The program thought the left mouse button was still pressed. I removed this by first waiting for the mouse cache to be empty before calling my own dialog, then calling the open Windows dialog.

Part of the code:

Code: QB64: [Select]

1. 'in my loop in begin is:
2. WHILE _MOUSEINPUT: WEND
3. LB = _MOUSEBUTTON(1)
4.  
5. 'own code
6.  
7. 'before call windows dialog
8. 'wait for erase mouse cache for left button                          
9.  DO UNTIL LB = 0
10.   WHILE _MOUSEINPUT: WEND
11.       LB = _MOUSEBUTTON(1)
12.    LOOP
13. 'after cleaning mouse cache call windows open dialog
14. Status$ = GetOpenFileName$("Navrhar 2", ".\", Filter$, 1, Flags&, _WINDOWHANDLE)
15.  

[bplus]

Welcome back Petr,

Yes I had similar problem trying to select off screen listing two arrays at same time trying separate mouse routine for each array, nope, need a central mouse routine and figure which array from that. I could get clear of click from one mouse routine but be right back in the middle of click in the 2nd, crazy!

[SpriggsySpriggs]

@Petr
Are you in 64 or 32 bit?

I'm almost positive that the TYPE is the wrong size because this is the OPENFILENAMEA structure from the MSDN:

Code: C++: [Select]

1. typedef struct tagOFNA {
2.   DWORD         lStructSize; //LONG
3.   HWND          hwndOwner; //LONG
4.   HINSTANCE     hInstance; //LONG
5.   LPCSTR        lpstrFilter; //_OFFSET
6.   LPSTR         lpstrCustomFilter; //_OFFSET
7.   DWORD         nMaxCustFilter; //LONG
8.   DWORD         nFilterIndex; //LONG
9.   LPSTR         lpstrFile; //_OFFSET
10.   DWORD         nMaxFile; //LONG
11.   LPSTR         lpstrFileTitle; //_OFFSET
12.   DWORD         nMaxFileTitle; //LONG
13.   LPCSTR        lpstrInitialDir; //_OFFSET
14.   LPCSTR        lpstrTitle; //_OFFSET
15.   DWORD         Flags; //LONG
16.   WORD          nFileOffset; //INTEGER
17.   WORD          nFileExtension; //INTEGER
18.   LPCSTR        lpstrDefExt; //_OFFSET
19.   LPARAM        lCustData; //_OFFSET
20.   LPOFNHOOKPROC lpfnHook; //_OFFSET
21.   LPCSTR        lpTemplateName; //_OFFSET
22.   LPEDITMENU    lpEditInfo; //_OFFSET
23.   LPCSTR        lpstrPrompt; //_OFFSET
24.   void          *pvReserved; //_OFFSET
25.   DWORD         dwReserved; //_OFFSET
26.   DWORD         FlagsEx; //_OFFSET
27. } OPENFILENAMEA, *LPOPENFILENAMEA;

It looks like our Wiki code is missing some variables in the TYPE definition. Also, we should probably change

Code: QB64: [Select]

1.     FUNCTION GetOpenFileNameA&& (DIALOGPARAMS AS FILEDIALOGTYPE) ' The Open file dialog
2.     FUNCTION GetSaveFileNameA&& (DIALOGPARAMS AS FILEDIALOGTYPE) ' The Save file dialog

to

Code: QB64: [Select]

1.     FUNCTION GetOpenFileNameA&& (DIALOGPARAMS AS _OFFSET) ' The Open file dialog
2.     FUNCTION GetSaveFileNameA&& (DIALOGPARAMS AS _OFFSET) ' The Save file dialog

since the MSDN shows we're to pass DIALOGPARAMS as a pointer to an OPENFILENAMEA structure. I bet this, along with the TYPE size and some other tweaks, will solve the mouse issue.

[Petr]

Hi SpriggsySpriggs, hi BPlus. I don't think it's the wrong TYPE field size. I added _DELAY .1 to a routine for clearing the mouse cache, and since then it works as I expected. I will enclose a very early and non-functional version of the program in which I solved it. But it's in Czech, I haven't intended to release this version yet. Deliberately, try it, under all versions of the IDE. The point is that the icon descriptions are always displayed after the windows dialogs are closed. To test, use the icons in the red circle in the picture, it's really a very early version that doesn't do anything yet (it doesn't save anything and none selected image is loade to  memory).

A description of the error that occurred before the adjustment would also be useful. The program called up the windows dialog box (any), and when the windows dialog box ended, program is behaved as if the left mouse button was still pressed. Maybe that's the bad design of the program. That is why I am attaching it to the assessment.

It behaved the same, in 32bit and 64bit and also in different versions of the IDE.

 

[Petr]

Oh yeee :) LB is not shared variable. So the solution must be just _DELAY .1 before is Windows dialogbox run.