Opened 5 years ago
Closed 4 years ago
#82 closed defect (fixed)
Save brush overwrite existing file fails
|Reported by:||Owned by:||pulkomandy|
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.
Change History (13)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
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).
comment:3 by , 4 years ago
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@…"
comment:4 by , 4 years ago
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.
comment:5 by , 4 years ago
thank, I've now access to the emails addresses.
I just sent a message to the reporter
comment:6 by , 4 years ago
Thanks for looking into this.
Steps to reproduce:
- Draw a point/square or something
- Create brush containing point
- Save brush as 1.gif
- Draw second point
- Create brush containg both points
- Save brush as 2.gif
- Draw third point
- Create brush containg all three points
- 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)
- 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
comment:7 by , 4 years ago
versions 1949 and 1982 are a few month old.
do you reproduce with the windows nightly build available on
(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)
comment:8 by , 4 years ago
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.
comment:9 by , 4 years ago
thanks. that must be a win32 specific bug
comment:10 by , 4 years ago
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, 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.
comment:11 by , 4 years ago
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
comment:12 by , 4 years ago
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.
comment:13 by , 4 years ago
|Status:||new → closed|
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.
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 ?