Posts:
4,171
Registered:
4-Aug-2006
|
|
|
Posts:
8,148
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 16:30
in response to: RobM
|
|
|
|
Worse. Blows up even when you are running from the regular app!
|
|
|
Posts:
4,171
Registered:
4-Aug-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 16:46
in response to: JeffTucker
|
|
|
Worse. Blows up even when you are running from the regular app!
It was a long shot, a very long shot.
Edited by: RobM on 29 Apr 2022, 15:47
Maybe it should have been context, console context explorer rootFolder |
|
|
Posts:
8,148
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 16:53
in response to: RobM
|
|
|
All far too byzantine. What's really needed is: if(isGUI()) do it this way;
else do it the other way;
ETA: But there's a long, proud tradition of coders using error traps for this kind of stuff. It's the lazy man's if/else clause.  |
|
|
Posts:
4,171
Registered:
4-Aug-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 17:01
in response to: JeffTucker
|
|
|
All far too byzantine. What's really needed is: if(isGUI()) do it this way;
else do it the other way;
ETA: But there's a long, proud tradition of coders using error traps for this kind of stuff. It's the lazy man's if/else clause.
Fortunately no one has, I’m sure, run any of my tools using rootFolder or currentFolder from the command line, so that only leave a couple of skins to not worry about  |
|
|
Posts:
710
Registered:
27-Sep-2003
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 18:11
in response to: JeffTucker
|
|
|
In console mode, "context.getExplorer()" is null (unsurprisingly).
Workaround: AlbumObject vRootFolder;
JAlbumExplorer jAlbumExplorer = context.getExplorer();
vRootFolder = (jAlbumExplorer == null ? rootFolder : jAlbumExplorer.getRootFolder());
|
|
|
Posts:
8,148
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
29 Apr 22, 19:04
in response to: ctwist
|
|
|
Ah, yes, of course.
But in the interests of conciseness, I prefer: if(context.getExplorer() == null) checkObjects(rootFolder);
else checkObjects(context.getExplorer().getRootFolder());
No need for declarations or new variables. |
|
|
Posts:
710
Registered:
27-Sep-2003
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
4 May 22, 06:10
in response to: JeffTucker
|
|
|
But in the interests of conciseness ......
My philosophy is to avoid calling a method twice with the same parameters, since this usually has a higher overhead than declaring an extra variable to hold the method's original result. Also, maintenance is slightly simpler, since there is one call to be maintained instead of two.
Of course in this situation (just one pair of calls), performance is not a concern, but in different circumstances it could be a consideration. |
|
|
Posts:
710
Registered:
27-Sep-2003
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
4 May 22, 07:03
in response to: ctwist
|
|
|
Here is one more related problem that I fixed.
In onload.bsh, I instantiate the MgSkin class: new MgSkin(engine);
This is visible to init.bsh.
While testing console mode in jAlbum 27, an exception occurred in init.bsh because a variable in MgSkin was null. This was all very reasonable, because onload.bsh had not been processed. I fixed it by adding if (context.getExplorer() == null)
{ new MgSkin(engine);
}
to init.bsh.
However I did not see this problem in the previous version of Mirage in the previous version of jAlbum. I have made lots of changes, so I may have caused this.
However, my point is: "If you do some initialisation in onload.bsh, you may have to redo this in init.bsh if you are running in console mode."
I have usually ignored console mode, so maybe I am preaching to the choir.
Edited by: ctwist on 4 May 2022, 01:41 |
|
|
Posts:
8,148
Registered:
31-Jan-2006
|
|
|
|
Re: Bug, or just changed behavior?
Posted:
4 May 22, 13:28
in response to: ctwist
|
|
|
My philosophy is to avoid calling a method twice with the same parameters, since this usually has a higher overhead than declaring an extra variable to hold the method's original result.
Especially for the things in init.bsh, which are usually one-shots, I go for readability. The overhead difference is probably in the sub-millisecond range. When it comes to "parsing the whole AO tree," it might pay to think about overhead. But even then, unless you're making one of those "holy crap," tens of thousands of images albums, the difference is probably tough to detect.
I'm also inclined to fall back on the fact that BeanShell is much less fussy about declarations and data typing than real Java. If I'm not compiling, it's just easier. It does give rise to bad habits, of course.  |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
