Save brush overwrite existing file fails

[approbo.games@…]

Attempting to save a brush overwriting an existing file fails if the save filename is already selected (after a previous save for example).

If the filename is not pre selected (first save) or a new filename is entered the brush saves correctly.

If the filename is preselected and another file is clicked, the screen colours mess up but if you then re-click the orginal pre selected file, the save is successful.

This could potentialy result in lost data if you don't check the brush was saved.

[Thomas Bernard]

I don't reproduce the issue.
Saving the brush by overwriting an existing file works well.

Is that possible to get more details from the user who reported the issue ?

[PulkoMandy]

They should get an email notification for all replies to the ticket (you should as well, but free.fr thinks emails sent from this server are spam).

You can send them an email directly if everything else fails (the full email should be visible when you are logged in, I think? If not I can try to change some permission settings to allow that).

[Thomas Bernard]

I now get the email notifications on my @free.fr address ! (but that is through the googlegroup ;)

and no, I don't see the full email address of the reporter. Only "approbo.games@…"

[PulkoMandy]

I granted you "developer" permissions now (you get access to Trac admin pages and I think to the mail addresses too).

Yes, the Google Group gets a notification of everything, but there is also direct emails to people involved in each ticket.

[Thomas Bernard]

thank, I've now access to the emails addresses.
I just sent a message to the reporter

[approbo.games@…]

Hi,

Thanks for looking into this.

Windows
grafx2-2.5.1949
grafx2-2.5.1982

Steps to reproduce:

1. Draw a point/square or something
2. Create brush containing point
3. Save brush as 1.gif

4. Draw second point
5. Create brush containg both points
6. Save brush as 2.gif

5. Draw third point
6. Create brush containg all three points
7. Go to Save brush, at this point 2.gif (previous file) is selected, click save. Save fails (Screen goes RED briefly but no error) file is unchanged (Still 2 points)
8. Go to Save brush, at this point 2.gif (previous file) is selected, click 1.gif, then click 2.gif again, click save. Save successfull

[Thomas Bernard]

versions 1949 and 1982 are a few month old.
do you reproduce with the windows nightly build available on
​http://grafx2.chez.com/index.php?static3/downloads ?
(should be grafx2-sdl-2.6wip2178.win32.exe / grafx2-win32-2.6wip2178.win32.exe)

(I do not reproduce your problem with the my current code)

[approbo.games@…]

Ok I tried with version: grafx2-2.6wip2178-win32

Still the same but the screen stays red after attempting to save the brush. I created a small video and uploaded to Google Drive showing this.

​https://drive.google.com/open?id=1MgLXBOR1ZtqNuxgHSLWwt56qnNrhLNR4

[Thomas Bernard]

thanks. that must be a win32 specific bug

[yrizoud@…]

I managed to reproduce it (Windows XP) and step through in debugger. It's in the Unicode handling.
In the second saving, Open_file_write() enters the block if (context->File_name_unicode != NULL), but although this pointer is indeed non-null, it is an empty string (first 'character' is zero). The code then mistakenly tries to open the directory for writing, fails, and stops.

I can see one place in code where a similar test is coupled with && context->File_name_unicode[0] != 0, but not here. And there are 4 other pieces of code that only test for NULL pointer.

Sorry I can't help more, I don't understand the Unicode part.

[Thomas Bernard]

I have made several fixes.
See : ​https://gitlab.com/GrafX2/grafX2/merge_requests/114

please test this version : ​https://gitlab.com/miniupnp/grafX2/-/jobs/118466970/artifacts/download

[approbo.games@…]

I can confirm the test build fixes the problem saving brushes relating to this ticket.
Thanks a lot!

The test build has other issues though, the interface doesn't redraw after window resize or maximise. I notice there's some other commits relating to this save fix - Window position saving etc, not sure if they are related to this problem.

[Thomas Bernard]

I'm indeed currently working on the win32-gdi resize / move etc.
Let test a nightly build in a few days and open a new ticket if there are still issues.