#1222 Script is run multiple times on one command

[David Ihnen]

Freemind 1.0.1

Windows 7 Professional SP1

Java version 8 Update 31 (build 1.8.0_31-b13)

I am trying to run a script ONCE per initiation (alt-f8/run command), but it appears to be run times the number of attempts to run scripts.

I put this Test script on the root node of a new mindmap:

def logger = c.getFrame().getLogger(this.getClass().getName());
logger.severe("HOW MANY?")

Then I open the logging console from the help menu

I then press Alt-F8.

HOW MANY (along with groovy noise) appears once.

I press it again.

HOW MANY (along with groovy noise) appears twice.

I press it again.

HOW MANY (along with groovy noise) appears thrice.

resulting mindmap looks like this:

<map version="1.0.1">
<!-- To view this file, download free mind mapping software FreeMind from http://freemind.sourceforge.net -->
<node CREATED="1424289517037" ID="ID_628288024" MODIFIED="1424291336193" TEXT="New Mindmap">
<attribute NAME="script1" VALUE="def logger = c.getFrame().getLogger(this.getClass().getName()); logger.severe("HOW MANY?")"/>
<attribute NAME="script2" VALUE="def logger = c.getFrame().getLogger(this.getClass().getName()); logger.severe("SOME MORE?")"/>
</node>
</map>

[David Ihnen]

On further code inspection is may well be that the logger objects are stacking up rather than reexecuting the script.

[David Ihnen]

From Freemind.java about line 871, this code removes the previously added logger handler for this logger class name by mirroring the style earlier when working with ConsoleHandler type. Far as I can tell we DO have to addHandler in order to get the messages out, but adding to the handler list every time we call getLogger() is a bit excessive, yes/no?

    if (sLogFileHandler != null) {
        final Handler[] handlers = loggerForClass.getHandlers();
        for (int i = 0; i < handlers.length; i++) {
            final Handler handler = handlers[i];
            if (handler == sLogFileHandler) {
                loggerForClass.removeHandler(handler);
            }
        }
        loggerForClass.addHandler(sLogFileHandler);
    }

[Christian Foltin]

Hi,

isn't it possible to use the controller's logger? like c.logger.severe("bla")?
HTH, Chris

[David Ihnen]

Only possible when cognizant that such a thing was available and appropriate. Being ludicrously novice about things java-like, the path I took was to look for how the code gets one when it needs one rather than snarfing class fields (which I only noticed after you mentioned such a thing) with assumption they're already initialized. That is, indeed, simpler. I suppose this demonstrates how novice programmers can reveal otherwise innocuous bugs. I hope you're not suggesting it is appropriate to stack up handlers merely because there is a workaround that doesn't.

[Christian Foltin]

Hi,

another possibility to imitate the java code is to use a static logger variable in groovy. I haven't tried this, so I'm not 100% sure that it works. Perhaps ,you can give it a try? (So far, I always println for debugging purposes. Thus, I haven't a solution prepared).

HTH, Chris

PS: Just my curiosity: What are you going to implement?

[David Ihnen]

You'd think, right? but even with your hint about static

static l = c.logger;def w (m) {l.severe(m)};w("TEST");

gives error

message: No such property: l for class: Script1Line number: -1

Curiously so does

import java.util.logging.*;Logger l = c.logger;def w (m) {l.severe(m)};w("TEST");

and this

import java.util.logging.*;private Logger l = c.logger;def w (m) {l.severe(m)};w("TEST");

but this doesn't give the error:

l = c.logger;def w (m) {l.severe(m)};w("TEST");

but mildly exasperates me because eclipse keeps indicating that it doesn't know what type l is.(I try to use my tools to make my code less buggy - it can't tell me there's a problem if it doesn't understand the type in the code) I'd like to TELL eclipse, but if I do, something odd happens with the scoping. Maybe you can explain what is going on here, I wish I understood.

I am implementing code that updates attributes in a subtree for dependency tracking (a dependency represented as a child node), so that I can then use a filter to display just the elements which don't currently have unfulfilled dependencies outstanding. like most projects, this one has hundreds of tasks each with its own node - finding the 'outstanding tasks' quickly is enabled by the attribute values updated by this script vs. the state attribute set on each task.