|
Replies:
24
-
Pages:
2
[
1
2
| Next
]
-
Last Post:
4 May 22, 13:28
Last Post By: JeffTucker
|
Threads:
[
Previous
|
Next
]
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Bug, or just changed behavior?
Posted:
23 Apr 22, 16:28
|
|
|
In my skins, I have a routine in init.bsh that excludes objects that aren't supported by the skin. A simple example, which excludes everything except images: private void checkObjects(AlbumObject ao) {
AlbumSynchronizer AlSy = new AlbumSynchronizer(engine);
for(AlbumObject obj : ao.getChildren()) {
cat = obj.getCategory();
if(obj.isIncluded()) {
if(obj.isFolder()) checkObjects(obj);
else {
if(cat != Category.image) {
obj.setIncluded(false);
AlSy.delete(obj);
areExclusions = true;
}
}
}
}
}
In prior versions of jAlbum, the "excluded" overlay would appear on the excluded objects immediately. Now they don't appear until the Explore view is refreshed somehow, either by hitting F5 or by navigating away from the top level, and then going back to it again. |
|
|
Posts:
4,073
Registered:
4-Aug-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
23 Apr 22, 18:30
in response to: JeffTucker
|
|
|
You used to include a line with ao.setChildren(ao.getChildren());
after the Iterator, could it be that? |
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
23 Apr 22, 19:21
in response to: RobM
|
|
|
|
The need for that went away along about jAlbum 17, if I'm reading the old threads correctly (search the forum for setChildren to find the various references).
I'll have to do some more testing. If albumfiles.txt is properly updated, and if "changed" subdirectories still get processed (and unchanged ones don't), the lack of visual feedback probably doesn't matter.
|
|
|
Posts:
4,073
Registered:
4-Aug-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
23 Apr 22, 19:29
in response to: JeffTucker
|
|
|
The need for that went away along about jAlbum 17, if I'm reading the old threads correctly (search the forum for setChildren to find the various references).
I'll have to do some more testing. If albumfiles.txt is properly updated, and if "changed" subdirectories still get processed (and unchanged ones don't), the lack of visual feedback probably doesn't matter.
Oh the joy of getting older, the number of these old threads where we keep saying ‘It’s all coming back’ or ‘I forgot…’. Still it’s beginning to come back to me now  |
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
23 Apr 22, 19:42
in response to: RobM
|
|
|
|
A useful exercise, in any event. I dropped back to jAlbum 26.2, and made an album that included a "forbidden" object. My existing checkObjects method works fine, and the result is immediately visible in the Explore view - no need for refreshing. In jAlbum 27.0.7, a refresh is required. I have no way of testing 27.0.0 through 27.0.6, of course.
So, my original question stands. Something has changed. Can it be fixed?
|
|
|
Posts:
4,066
Registered:
18-Oct-2002
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
26 Apr 22, 13:55
in response to: JeffTucker
|
|
|
|
I'm actually surprised that you haven't had the need to execute a refresh previously, cause, within init.bsh, you're dealing with a copy of the AlbumObject tree that jAlbum's explorer uses, and changes to the copy don't automatically propagate to the original AlbumObject tree. Try manipulating the original tree instead, which is accessible through context.getExplorer().getRootFolder(). Just be ware that context.getExplorer() will return null when running from the console.
|
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
26 Apr 22, 13:59
in response to: davidekholm
|
|
|
|
You have now lost me completely.
ETA: Remember, this worked flawlessly in jAlbum 26.
|
|
|
Posts:
4,066
Registered:
18-Oct-2002
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
26 Apr 22, 14:00
in response to: JeffTucker
|
|
|
|
Try repacing the rootFolder reference in your code with context.getExplorer().getRootFolder().
|
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
26 Apr 22, 14:04
in response to: davidekholm
|
|
|
Well, that seems to work.
I'll just pretend that I understand why. Won't be the first time.  |
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
26 Apr 22, 20:39
in response to: JeffTucker
|
|
|
One interesting little wrinkle. More amusing than anything else, since it's easily worked around.
If a project contains its own res folder, traversing the copy of the AO tree happily ignored it. So, a favicon.ico file didn't get excluded - the file exclusion routine simply never saw it. It wasn't present in the copy of the AO tree.
But using the original AO tree, it's there! I don't want to ignore all hidden files, but a quick check for a res folder name easily takes care of it. The first time I remade an older project, I got the skin warning that it was excluding some files. Where it was coming from puzzled me for a while. |
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 14:50
in response to: davidekholm
|
|
|
Try repacing the rootFolder reference in your code with context.getExplorer().getRootFolder().
A problem with doing this. You can't do it from the command line! Smoke, flames.
I suppose I can error trap this, and fall back to using just rootFolder in that case. |
|
|
Posts:
4,073
Registered:
4-Aug-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 15:14
in response to: JeffTucker
|
|
|
Try repacing the rootFolder reference in your code with context.getExplorer().getRootFolder().
A problem with doing this. You can't do it from the command line! Smoke, flames.
I suppose I can error trap this, and fall back to using just rootFolder in that case.
The command line parameters do not include rootFolder or currentFolder, so how can you fallback to them? |
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 15:22
in response to: RobM
|
|
|
The command line parameters do not include rootFolder or currentFolder, so how can you fallback to them?
I'm talking about building albums from a script, with lines like: "C:\Program Files\jAlbum\jre64\bin\java" -Xmx800M -jar "C:\Program Files\jAlbum\JAlbum.jar" -projectFile "ATdark.jap"
I do that so that I can rebuild all of my demo albums from a script, rather than opening each one in the app and hitting F9. Change directory, make album, change directory, etc.
The fix is in the skin's init.bsh. Just did one skin and tested, and it behaves just fine: // Exclude unsupported objects and use original GIF's
areExclusions = false;
try {
checkObjects(context.getExplorer().getRootFolder());
}
catch(Exception e) {
checkObjects(rootFolder);
}
if(areExclusions) atWarning("Unsupported objects excluded from album project.");
Surprisingly, the warning dialog appears in the Windows command line window (think "Terminal")! |
|
|
Posts:
4,073
Registered:
4-Aug-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 16:02
in response to: JeffTucker
|
|
|
The command line parameters do not include rootFolder or currentFolder, so how can you fallback to them?
I'm talking about building albums from a script, with lines like: "C:\Program Files\jAlbum\jre64\bin\java" -Xmx800M -jar "C:\Program Files\jAlbum\JAlbum.jar" -projectFile "ATdark.jap"
I do that so that I can rebuild all of my demo albums from a script, rather than opening each one in the app and hitting F9. Change directory, make album, change directory, etc.
The fix is in the skin's init.bsh. Just did one skin and tested, and it behaves just fine: // Exclude unsupported objects and use original GIF's
areExclusions = false;
try {
checkObjects(context.getExplorer().getRootFolder());
}
catch(Exception e) {
checkObjects(rootFolder);
}
if(areExclusions) atWarning("Unsupported objects excluded from album project.");
Surprisingly, the warning dialog appears in the Windows command line window (think "Terminal")!
I see a nice rabbit hole to explore, an api method that lets us know if jAlbum is running with or without a gui. That would seem better than catching an error, not sure if there is such a method. |
|
|
Posts:
8,034
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 16:06
in response to: RobM
|
|
|
|
Let us know when you come up for air.
|
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
