Only search projects.blender.org
 Log In
New Account
Home My Page Projects Blender 2.x BF release
Summary Activity Tracker SCM Files

Blender 2.6 Bug Tracker: Browse

[#20812] User preference window is not closing after browsing font's directory

Date:
2010-01-25 12:26		 Priority:
3
State:
Closed
Submitted by:
Seppo Tukiainen (raportoi) 		Assigned to:
Ton Roosendaal (ton)
Category:
Interface		 Status:
Fixed / Closed
Relates to:
Duplicates:
Patches:
 
Summary:
User preference window is not closing after browsing font's directory
Detailed description
WIN Vista32 + r26234:
Normally, setting "User Preferences" selections to be used as a defaults with "Save As Default" button, firs the preferences window is closed and then the defaults are set.
But after browsing the font's directory, prefereces window is not closed by the save button.
Then loading the "Start-Up File" the preference window is opened along.

Followup

Message
  • Date: 2010-01-27 07:44
  • Sender: Matt Ebb
  • Dev note: strangely the sc->full is getting reset to zero somewhere, rather than being SCREENTEMP as it should be...
  • Date: 2010-01-27 17:38
  • Sender: Seppo Tukiainen
  • More info:
    Seems that it doesn't matter which directory is being browsed.
  • Date: 2010-01-28 02:05
  • Sender: Matt Ebb
  • I spent a while trying to debug this one, very mysterious and confusing.

    The problem seems to be that the screen attached to sa->full
    sc= sa->full; /* the old screen to restore */ (line 1460 in screen_edit.c)

    always has its 'full' variable, sc->full set to 0.

    But in WM_write_homefile() wm_files.c, it checks to see if the screen->full == SCREENTEMP before closing it.

    I tried various attempted fixes, removing the sc->full= 0; line from ed_screen_fullarea() and updating the code, or making screen->full a bitflag rather than enum (so it can be both SCREENTEMP and SCREENFULL at the same time) and modifying the code accordingly, but I'm still stuck.

    Assigning to Ton, since he probably understands this part of the code best...
  • Date: 2010-01-28 06:15
  • Sender: Seppo Tukiainen
  • There is bug report entry #20789, which I think is related to this, and migth have some glue.
    Pls. read that!
  • Date: 2010-11-09 15:55
  • Sender: Ton Roosendaal
  • Fix goes to svn now! See commit for extensive report.
 

Attached Files:

No Files Currently Attached

Changes:

Field Old Value Date By
ResolutionNone2010-11-09 15:55ton
close_date2010-11-09 15:552010-11-09 15:55ton
status_idOpen2010-11-09 15:55ton
assigned_tonone2010-01-28 02:05broken