The build [VASSAL-3.2.0-svn7890-windows.exe] is setting off my malware detection software.
Any comment?
Flaney
Thus spake Flaney:
The build [VASSAL-3.2.0-svn7890-windows.exe] is setting off my malware
detection software.Any comment?
Your malware detection software is wrong. What is it that you’re using?
–
J.
I am using Malwarebytes’ Anti-Malware portable apps. I also got a yahoo download message indicating the file had a virus (I uploaded to yahoo mail so that I could download at work during lunch: vassalengine.org block by employer).
flaney
Thus spake Flaney:
I am using Malwarebytes’ Anti-Malware portable apps. I also got a yahoo
download message indicating the file had a virus (I uploaded to yahoo
mail so that I could download at work during lunch: vassalengine.org
block by employer).
I don’t know what to tell you other than that they’re mistaken.
–
J.
Thus spake pgeerkens:
#7836: __AutoExecGKC __implementation automatically runs a GKC on
game-start-up
I get an NPE when I try adding an AutoExecGKC with this changeset
applied to trunk@7898:
va.lang.NullPointerException: null
at VASSAL.counters.GlobalCommand.setKeyStroke(GlobalCommand.java:55) ~[classes/:na]
at VASSAL.build.module.map.MassKeyCommand.setAttribute(MassKeyCommand.java:464) ~[classes/:na]
at VASSAL.build.module.AutoExecGKC.setAttribute(AutoExecGKC.java:120) ~[classes/:na]
at VASSAL.configure.AutoConfigurer.propertyChange(AutoConfigurer.java:200) ~[classes/:na]
at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:298) ~[na:1.6.0_22]
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:291) ~[na:1.6.0_22]
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:229) ~[na:1.6.0_22]
at VASSAL.configure.Configurer.setValue(Configurer.java:104) ~[classes/:na]
at VASSAL.configure.HotKeyConfigurer.setValue(HotKeyConfigurer.java:49) ~[classes/:na]
at VASSAL.configure.HotKeyConfigurer.setValue(HotKeyConfigurer.java:65) ~[classes/:na]
at VASSAL.configure.AutoConfigurer.(AutoConfigurer.java:87) ~[classes/:na]
at VASSAL.build.AbstractConfigurable.getConfigurer(AbstractConfigurable.java:173) ~[classes/:na]
at VASSAL.configure.ConfigureTree$7.actionPerformed(ConfigureTree.java:535) ~[classes/:na]
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012) ~[na:1.6.0_22]
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335) ~[na:1.6.0_22]
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404) ~[na:1.6.0_22]
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) ~[na:1.6.0_22]
at javax.swing.AbstractButton.doClick(AbstractButton.java:374) ~[na:1.6.0_22]
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:829) ~[na:1.6.0_22]
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:873) ~[na:1.6.0_22]
at java.awt.Component.processMouseEvent(Component.java:6268) ~[na:1.6.0_22]
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267) ~[na:1.6.0_22]
at java.awt.Component.processEvent(Component.java:6033) ~[na:1.6.0_22]
at java.awt.Container.processEvent(Container.java:2045) ~[na:1.6.0_22]
at java.awt.Component.dispatchEventImpl(Component.java:4629) ~[na:1.6.0_22]
at java.awt.Container.dispatchEventImpl(Container.java:2103) ~[na:1.6.0_22]
at java.awt.Component.dispatchEvent(Component.java:4455) ~[na:1.6.0_22]
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4633) ~[na:1.6.0_22]
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4297) ~[na:1.6.0_22]
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4227) ~[na:1.6.0_22]
at java.awt.Container.dispatchEventImpl(Container.java:2089) ~[na:1.6.0_22]
at java.awt.Window.dispatchEventImpl(Window.java:2517) ~[na:1.6.0_22]
at java.awt.Component.dispatchEvent(Component.java:4455) ~[na:1.6.0_22]
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:649) ~[na:1.6.0_22]
at java.awt.EventQueue.access$000(EventQueue.java:96) ~[na:1.6.0_22]
at java.awt.EventQueue$1.run(EventQueue.java:608) ~[na:1.6.0_22]
at java.awt.EventQueue$1.run(EventQueue.java:606) ~[na:1.6.0_22]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.6.0_22]
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105) ~[na:1.6.0_22]
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:116) ~[na:1.6.0_22]
at java.awt.EventQueue$2.run(EventQueue.java:622) ~[na:1.6.0_22]
at java.awt.EventQueue$2.run(EventQueue.java:620) ~[na:1.6.0_22]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.6.0_22]
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105) ~[na:1.6.0_22]
at java.awt.EventQueue.dispatchEvent(EventQueue.java:619) ~[na:1.6.0_22]
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275) [na:1.6.0_22]
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200) [na:1.6.0_22]
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) [na:1.6.0_22]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185) [na:1.6.0_22]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177) [na:1.6.0_22]
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138) [na:1.6.0_22]
23:20:46.885 [AWT-EventQueue-0] INFO VASSAL.build.GameModule - Exiting
23:20:47.266 [IPC receiver for 831667365] ERROR VASSAL.tools.ipc.IPCMessageReceiver -
java.io.EOFException: null
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2570) ~[na:1.6.0_22]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314) ~[na:1.6.0_22]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368) ~[na:1.6.0_22]
at VASSAL.tools.ipc.IPCMessageReceiver.run(IPCMessageReceiver.java:34) ~[classes/:na]
at java.lang.Thread.run(Thread.java:679) [na:1.6.0_22]
#7839: documentation for AutoExecGKC
Lowercase the extension of the image you added. 
Also, I think a better name for this might be StartupGlobalKeyCommand.
–
J.
I’m looking at this now.
Once I fix the error, you can rename as you wish - but there are a half dozen module developers who are already using it under the current name.
Once it is merged they can remove the custom class and use it instead. A
custom class is not needed in a module once it becomes part of the core so
renaming it for core should not be an issue
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of pgeerkens
Sent: Tuesday, October 11, 2011 5:38 PM
To: messages@vassalengine.org
Subject: [messages] [Developers] Re: Check-ins for 3.2
I’m looking at this now.
Once I fix the error, you can rename as you wish - but there are a half
dozen module developers who are already using it under the current name.
Read this topic online here:
https://forum.vassalengine.org/t/check-ins-for-3-2/4306/18
Is it legal for
getAttributeValueString()
to return null instead of “”?
That is what is causing the problem.
Brent! You out there tonight?
My AutoExecGKC is inheriting a null ‘name’ from GlobalKeyCommand; so I need to know from Brent what the rules are for 'name’s of GKC’s to know how to fix the error.
Hi Pieter,
I am on IRC now.
Brent.
Pieter,
It may be blank, but it shouldn’t be null.
Brent.
try svn7902 in pgeerkens-3.2
Make that svn7904. I forgot to defer to super when not assigning visibility myself.
Thus spake pgeerkens:
Make that svn7904. I forgot to defer to super when not assigning
visibility myself.
That fixes the exception I had.
There’s one more thing which I think should be done here before I merge:
You say in the documentation that if there’s more than one AutoExecGKC,
the execution order is undefined, so it’s better to create a
MultiActionButton nested in a single AutoExecGKC if multiple commands
are desired. This makes me think that we simply shouldn’t permit there
to be more than one AutoExecGKC in the build tree, since the alternative
will lead to confusing, undesired behavior.
There’s a class calledSingleChildInstance which is used to prevent dupes
from being added to the build tree. Maybe AutoExecGKC should be set up
with one of those. Thoughs?
–
J.
Good idea. Let me check that out and see what is involved with implementing that.
Hmm! A first quick test and validator does nothing, not even a report of improper activity. I will check it out.
From memory, the validators only run when you try and save the module.
*********** REPLY SEPARATOR ***********
On 19/10/2011 at 4:28 PM pgeerkens wrote:
Hmm! A first quick test and validator does nothing, not even a report of
improper activity. I will check it out.
Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au
I think I can safely say that SingleChildInstance is a stub that never got completed. Not only is it only capable of saying “Naughty boy!”, it doesn’t even ever say that because the instantiators appear never to call the validate method:
[code]/**
- Ensures that at most a single instance of a given type
- belongs to a given parent
*/
public class SingleChildInstance implements ValidityChecker {
private AbstractConfigurable target;
private Class<?> childClass;
public SingleChildInstance(AbstractConfigurable target,
Class<?> childClass) {
this.childClass = childClass;
this.target = target;
}
public void validate(Buildable b, ValidationReport report) {
if (b == target && target.getComponentsOf(childClass).size() > 1) {
report.addWarning(
"No more than one " +
ConfigureTree.getConfigureName(childClass) +
" allowed in " +
ConfigureTree.getConfigureName(target));
}
}
}[/code]
Now the question is how should it work? It seems to me that the method validate of interface ValidityChecker needs to return a boolean with semantics “reject!” in addition to reporting the violation. Also, I believe this check should control the “enabled” status of the component on the drop-down menu, not be an after-the-fact error logger. Thoughts?
Pieter,
I believe that’s how the current validator works. From memory, at the time you save a module, all Buildables in the module are traversed and have any attached ValidityCheckers run and an ‘Are you sure?’ dialog is shown at the end. No attempt is made to prevent the illegal components from being saved. They are treated as warnings rather than errors.
B.
*********** REPLY SEPARATOR ***********
On 19/10/2011 at 4:52 PM pgeerkens wrote:
I think I can safely say that SingleChildInstance is a stub that
never got completed. Not only is it only capable of saying “Naughty
boy!”, it doesn’t even ever say that because the instantiators appear
never to call the __validate __method:Code:
/**
- Ensures that at most a single instance of a given type
- belongs to a given parent
*/
public class SingleChildInstance implements ValidityChecker {
private AbstractConfigurable target;
private Class<?> childClass;public SingleChildInstance(AbstractConfigurable target,
Class<?> childClass) {
this.childClass = childClass;
this.target = target;
}public void validate(Buildable b, ValidationReport report) {
if (b == target && target.getComponentsOf(childClass).size() > 1) {
report.addWarning(
"No more than one " +
ConfigureTree.getConfigureName(childClass) +
" allowed in " +
ConfigureTree.getConfigureName(target));
}
}
}Now the question is how should it work? It seems to me that the method
__validate __of interface __ValidityChecker __needs to return a boolean
with semantics “reject!” in addition to reporting the violation. Also, I
believe this check should control the “enabled” status of the component
on the drop-down menu, not be an after-the-fact error logger. Thoughts?
Read this topic online here:
Check-ins for 3.2 - #30 by pgeerkens
messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1411 / Virus Database: 1522/3962 - Release Date: 10/19/11
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1411 / Virus Database: 1522/3962 - Release Date: 10/19/11
Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au
Hi Brent,
Yes, I understand form a backwards-compatibility standpoint why they are
only warnings when detected after-the-fact,; but going forward it would be
nice to prevent creation of unsuitable structures.
I have been looking at ConfigureTree, and expect to get the changes done by
tomorrow. I will add an interface SingleChildInstanceOnline (or whatever
Joel suggests as an alternative that ugly moniker) and for all children
implementing that interface I will set/clear the enabled flag of the
drop-down menu action and the valid paste-target flag on whether the current
child count of that type is =0 or >0.
It must be your lunch-time about now I expect. My other project this week
is to finish up GridShear to obsolesce the current GridEditor (almost).: The
UI will be:
Drag-and-drop one hex center/corner onto the map-grid as a first fixed
point;
Drag-and-drop a second hex center/corner as a rotation/scaling about FP1 to
size and roughly align the grid, also setting a second fixed-point; then
Drag-and-drop a third hex corner/center as a shearing operation about the
first two.
Step three is already done, and works nicely, relying on the existing Grid
Editor to achieve the effect of 1 & 2. The twist introduced by cheap /old
scanners is easily eliminated, and combined with my proper hex-snapping
algorithm I believe behaves really professional.
Pieter
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Brent Easton
Sent: Wednesday, October 19, 2011 10:19 PM
To: messages@vassalengine.org
Subject: Re: [messages] [Developers] Re: Check-ins for 3.2
Pieter,
I believe that’s how the current validator works. From memory, at the time
you save a module, all Buildables in the module are traversed and have any
attached ValidityCheckers run and an ‘Are you sure?’ dialog is shown at the
end. No attempt is made to prevent the illegal components from being saved.
They are treated as warnings rather than errors.
B.
*********** REPLY SEPARATOR ***********
On 19/10/2011 at 4:52 PM pgeerkens wrote:
I think I can safely say that SingleChildInstance is a stub that
never got completed. Not only is it only capable of saying “Naughty
boy!”, it doesn’t even ever say that because the instantiators appear
never to call the __validate __method:Code:
/**
- Ensures that at most a single instance of a given type
- belongs to a given parent
*/
public class SingleChildInstance implements ValidityChecker {
private AbstractConfigurable target;
private Class<?> childClass;public SingleChildInstance(AbstractConfigurable target,
Class<?> childClass) {
this.childClass = childClass;
this.target = target;
}public void validate(Buildable b, ValidationReport report) {
if (b == target && target.getComponentsOf(childClass).size() > 1) {
report.addWarning(
"No more than one " +
ConfigureTree.getConfigureName(childClass) +
" allowed in " +
ConfigureTree.getConfigureName(target));
}
}
}Now the question is how should it work? It seems to me that the method
__validate __of interface __ValidityChecker __needs to return a boolean
with semantics “reject!” in addition to reporting the violation. Also,
I believe this check should control the “enabled” status of the
component on the drop-down menu, not be an after-the-fact error logger.
Thoughts?
Read this topic online here:
Check-ins for 3.2 - #30 by pgeerkens
messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1411 / Virus Database: 1522/3962 - Release Date: 10/19/11
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1411 / Virus Database: 1522/3962 - Release Date: 10/19/11
Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au