I have done some more snooping into the cause of this bug after more
direction and advice from Larry.
The LayerManager.addCategory() method calls the
LayerManager.fireCategoryChanged() method. The
LayerManager.fireCategoryChanged() sets up a loop. In each iteration of this
loop the LayerManager.f
Hi,
I do not know this plugin very well. Seems to allow 4 kind of spatial
joins :
For one of the following condition :
if a feature of layer A equals (resp. within or equalsAndWithin or
equalsOrWithin) a feature of layer B
creates a new Feature with the geometry of layer A feature and with the
Could be I twisted my english too far and it broke. ;-)
Larry
On 1/18/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> This is one of those pieces of code that the more I look at it, the more
> I see I don't see. Know what I mean?
i dont understand that really
but i know that i do not unde
O.K Stefan. I'll go with 1.2.0 for the version number?
A couple more questions:
[1] Where do I find the properties file that you mentioned?
[2] Are we displaying an image over a label in the splash screen?
Thanks for the help.
SS
On 1/18/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
it
I agree that it should be based on JUMP versions. I have been trying to
come up with a good scheme for SkyJUMP version to keep then in sync as much
as possible. I think I'm using 1.2.2 build 78 right now, but would be
willing to standardize if it would help keep users from getting confused.
Lar
> This is one of those pieces of code that the more I look at it, the more
> I see I don't see. Know what I mean?
i dont understand that really
but i know that i do not understand.. thats why i am a GIS guy and not a
programmer :o)
good night, stefan
-
it is done in the jump.properties file if you look for this string:
JUMPWorkbench.version.number=1.1 B
That means i have disabled the use of JUMPVersion for the splashscreen.
But the number original number is still used for the About.. screen.. so
that one can see which original JUMP version is
I'd like to know the answer to this one too.
Larry
On 1/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
Michael,
Looks like Stefan is hot on the trail of my bug!
Would you be able to breifly decribe the purpose of this command and how
it works?
Thanks,
The Sunburned Surveyor
On 1/18
Michael,
Looks like Stefan is hot on the trail of my bug!
Would you be able to breifly decribe the purpose of this command and how it
works?
Thanks,
The Sunburned Surveyor
On 1/18/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
Hei Michael,
thanx! i fixed it. But i wonder why the followin
Hello,
I think you caught another bug with
else if (nbFeatureWithin == 1) appearing two times
but
else if (nbFeatureEqualAndWithin == 1)
is different from
else if (nbFeatureEqualOrWithin == 1)
I'm close to get a write access to CVS
Hope next time, i'll fix it myself
Michaël
Stefan
I know exactly what you mean! I'm sorry I ever selected this bug out of the
tracker. :]
I should have followed the method calls that result from the call to
LayerManager.fireCategoryChanged() farther down the chain than I did.
I would still like to understand how things are working. I will print
Don't really know, but I would guess that the reason you aren't getting the
automatic version number on the splash screen that JUMP and SkyJUMP are
getting is that the OJ splash.png isn't the same size as the original. You
might have to modify SplashPanel.jbInit's constants for panel size.
regar
Stefan,
I forgot to clarify one thing you mentioned in the last e-mail. I was hoping
this work I've been doing would apply to the next official release of
OpenJUMP. I don't really have a "personal edition" like so many others. :]
Is this also what you had in mind? If you want I will make sure yo
Sunburned,
Well, it calls fireLayerEvent with a new inline Runnable class method run
defined to do layerListener.categoryChanged. Then fireLayerEvent invokes
GUIUtil.invokeOnEventThread which does:
if (SwingUtilities.isEventDispatchThread()) {
r.run();
} else {
Stefan,
My main concern was with the version shown on the splash screen. It sounds
like this is modified somewhere else? If you can show me how to change that
I see no need to change the rest of the splash screen.
I thought is was typical to have a XX.XX.XX version numbering scheme. I may
have b
Hei Michael,
thanx! i fixed it. But i wonder why the following lines appear two times
else if (nbFeatureWithin == 1){
mapping.transferAttributes(fEqual, aFeature, feature);
feature.setGeometry((Geometry) aFeature.getGeometry().clone());
fcRecup.add(feature)
Hej,
question 1)
01.00.02 mhm .. i wonder what you are releasing with respect to the
version number. the last official version has been 1.0.1
question 2)
is there a reason to change the splash screen? If you want to change it
for your personal edition .. why not? but i am quite happy with the
I knew it was something quick and easy.
Thanks Larry.
SS
On 1/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
Just replace
/openjump/src/com/vividsolutions/jump/workbench/ui/images/splash.png
Larry
On 1/18/07, Sunburned Surveyor < [EMAIL PROTECTED]> wrote:
> I'd like to update the splash s
Larry,
You could be right. I didn't even think about the iteration occuring in the
GUI Thread. Does this mean that the Runnable argument passed to the
LayerManager.fireCategoryChanged() method is in fact the GUI Thread? It
looked like OpenJUMP/JUMP was creating a brand new thread using an inner
c
Just replace
/openjump/src/com/vividsolutions/jump/workbench/ui/images/splash.png
Larry
On 1/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
I'd like to update the splash screen for the 01.00.02 release of OpenJUMP.
Can anyone give me some quick pointers on how to do that?
Thanks,
SS
P.
Sunburned,
I respectfully disagree with your analysis. I believe all of the
iteration over LayerListeners occurs within the GUI Thread. My guess is that
although addCategory took the bullet, it didn't fire the gun. Having said
that, and looking at the trace, and your fix, I don't see any harm
Hi Sunburned :
There is probably a "copy/paste" bug line 173 of SpatialJoinPlugIn class :
else if (methodName.equals(METHOD_WITHIN)) {
if (aFeature.getGeometry().within(bFeature.getGeometry())) {
nbFeatureWithin++;
nbFeature++;
fEqual = bFeature;
}
It should be fWithin instead of
Sorry,
I meant to label this as Bug #1546889, but I forgot to put it in the subject
line.
SS
On 1/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
I'm working on my second bug for the 01.00.02 OpenJUMP release. This bug
was reported by Johannes Metzler on 2006-08-25. His error involved th
I'm working on my second bug for the 01.00.02 OpenJUMP release. This bug was
reported by Johannes Metzler on 2006-08-25. His error involved the
Sigle-Geoprocessing "Transfer Attributes" command. He got a
NullPointerException while using this command, and I did as well. (I did get
it to work one of
I'd like to update the splash screen for the 01.00.02 release of OpenJUMP.
Can anyone give me some quick pointers on how to do that?
Thanks,
SS
P.S. - I hav created an SVG file for the OpenJUMP Kangaroo. I will make this
and a new JPP logo available to everyone on the SurveyOS website soon.
---
I have attached the Java file for the modified LayerManager class that fixes
Pedro's bug with the ConcurrentModificationException. All of the changes
were made to the LayerManager.fireCategoryChanged() method. I implemented
the solution recommended by David, which is to clone the layerListener
col
Larry,
I must apologize for my lack of good communication!
In the case of Pedro's bug a call to the LayerManager.addCategory() method
results in a call to the LayerManager.fireCategoryChanged() method which in
turn calls the LayerManager.fireLayerEvent() method. The
LayerManager.fireLayerEvent()
Sunburned,
It sounds like you have been studying up on the JUMP core quite a bit
lately, and have reached a pretty good understanding of how it works.
However, I'm confused about what the topic of Threads has to do with this
bug fix. Events are not Threads, as I'm sure you realize. As far as
David and Larry,
Thanks for the help. My comments are listed below.
Larry wrote: "If I understand the bug in question, it is not easy to
reproduce. It has been my experience that you can't fix bugs unless you can
reproduce them, otherwise you can't know when they are fixed. All you can
do othe
SS,
I think you've found the issue; thanks for the explanation. I wouldn't
worry about calling a listener with the event after it has been
de-registered because the event handlers are not guaranteed to be
executed in any given order.
In a perfect world (and the way most of us think about e
Hi Sunburned,
If I understand the bug in question, it is not easy to reproduce. It has
been my experience that you can't fix bugs unless you can reproduce them,
otherwise you can't know when they are fixed. All you can do otherwise is
to apply a lot of preventative measures that may improve th
I'm afraid I have to again correct my observations on Bug #1487099. I was
looking at the LayerManager class this morning and realized that the method
causing Pedro's ConcurrentModificationException hasn't yet been fixed by
creating a copy of the LayerListener collection. This fix was applied by Jo
On Thursday 18 January 2007 01:05, Sunburned Surveyor wrote:
> Did you know that Geoff is also working on a printing extension for
> OpenJUMP? Perhaps you guys could work together on this?
When Geoffrey posted here, I dropped a note that we are available
on this list for discussion.
However, it se
33 matches
Mail list logo
