| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #872
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | getUserdataPath from group-derived Fl_Preferences |
|---|
| Version: | 1.1-current |
|---|
| Created By: | Natevw |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | 1.1-current (SVN: v4361) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | Natevw
21:24 May 18, 2005 |
| The getUserdataPath does not seem to work from a preferences group constructed from a previous preference instance. It leaves the string untouched.
thanks,
-nate
#include <FL/Fl_Preferences.H>
main() {
Fl_Preferences one( Fl_Preferences::USER, "nvwuninc", "test" );
Fl_Preferences two( one, "folder");
char path[1024];
memset(path,0,1024);
{
two.getUserdataPath(path,1024);
fprintf(stderr,"%s\n",path); } // nothing.
{ // switching section order, both 'work'
one.getUserdataPath(path,1024);
fprintf(stderr,"%s\n",path); }
} | |
| |
| #2 | matt
06:46 May 19, 2005 |
| Thanks, I will look into this. | |
| |
| #3 | mike
07:15 May 19, 2005 |
| Seems like the second form of the constructor isn't copying the root node value.
Matthias, is there a reason for this? If not, I propose setting the rootNode to the parent's root node and only deleting the root node in the destructor if node->parent_ is NULL. | |
| |
| #4 | matt
07:24 May 19, 2005 |
| Ah, sure, that would break it. I won't be able to look at it befor Monday, so if you do have the time, it would be great if you could fix it.
Thanks! | |
| |
| #5 | mike
08:56 May 19, 2005 |
| Matthias, not sure what you mean about:
Ah, sure, that would break it.
Do you mean that my proposed fix would break things, or that the current way it is implemented is broken? | |
| |
| #6 | matt
10:41 May 19, 2005 |
| Having the rootNode pointer set to NULL would break the function to get the path. Sorry for being wishi washi. Without diving into the code, your proposal will most likely fix the bug reported here. I give it a +1. | |
| |
| #7 | mike
19:07 May 19, 2005 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
