Opened 6 years ago

Closed 6 years ago

#82 closed defect (fixed)

Save brush overwrite existing file fails

Reported by:… Owned by: pulkomandy
Priority: critical Milestone: 2.6
Component: GrafX2 Version: 2.5
Keywords: Cc:


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 Thomas Bernard, 6 years ago

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 ?

comment:2 by PulkoMandy, 6 years ago

They should get an email notification for all replies to the ticket (you should as well, but 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 Thomas Bernard, 6 years ago

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

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

comment:4 by PulkoMandy, 6 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 Thomas Bernard, 6 years ago

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

comment:6 by…, 6 years ago


Thanks for looking into this.


Steps to reproduce:

  1. Draw a point/square or something
  2. Create brush containing point
  3. Save brush as 1.gif
  1. Draw second point
  2. Create brush containg both points
  3. Save brush as 2.gif
  1. Draw third point
  2. Create brush containg all three points
  3. 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)
  4. 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 Thomas Bernard, 6 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…, 6 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 Thomas Bernard, 6 years ago

thanks. that must be a win32 specific bug

comment:10 by yrizoud@…, 6 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] != 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:12 by…, 6 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 Thomas Bernard, 6 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.