| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1025
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | suspicious code in Fl_Preferences::Node::remove() ? |
|---|
| Version: | 1.1-current |
|---|
| Created By: | a.rburgers.quicknet |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1.7 (SVN: v4576) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | a.rburgers.quicknet
10:46 Sep 16, 2005 |
| At the end of Fl_Preferences::Node::remove() there
is this piece of code:
}
delete this;
dirty_ = 1;
return ( nd != 0 );
}
Isn't the assignment dirty_ = 1 (this->dirty_ = 1) strange
after this has been deleted? Is nd valid just before the return? | |
| |
| #2 | matt
13:58 Sep 19, 2005 |
| This is indeed wrong. I beleive the idea was to set the dirty flag of the associtaed Fl_Preferences class. Anyway, thanks for finding this. I will investigate. | |
| |
| #3 | matt
14:11 Sep 19, 2005 |
| Fixed in Subversion repository.
Yes, it was upposed to set dirty_ in the parent | |
[ Return to Bugs & Features ]
|
| |
