[udig-devel] Problem with FeatureCollection, FeatureTableControl and CollectionListener

Ingmar Eveslage eveslage at gmail.com
Sat Feb 16 10:51:29 PST 2008


Thanks. I first should switch to trunk. i hope this is not so difficult.

Greats Ingmar

Am 15.02.2008 um 14:03 schrieb Jesse Eichar:

> So I've updated that class and in doing so realized that there are  
> two classes with the same name.  You might consider looking at the  
> other implementation.  It is what we use for the TableView.  It has  
> a bit more functionality.  But see if it fits your requirements.
>
> Jesse
>
> Le 15-Feb-08 à 2:40 AM, Ingmar Eveslage a écrit :
>
>> Hi Jesse,
>>
>> Am 15.02.2008 um 06:09 schrieb Jesse Eichar:
>>
>>> Hi Ingmar,
>>>
>>> So I have a few points.
>>>
>>> 1.  I think in the case of the Geometry column always being  
>>> GEOMETRY isn't actually caused by createTemporaryResource().  I  
>>> just checked.  You can see the feature type of a layer by right  
>>> click on a layer and viewing its properties.
>>> 2.  I am dragging this out of the dark corners of my mind but if I  
>>> remember correctly it is actually the FeatureTableControl that  
>>> does that.  For some reason the implementor decided to label the  
>>> Geometry column GEOMETRY always.  And I think it just displays the  
>>> type of geometry.
>> OK. But this isnt a very good choice, because you get an exception  
>> when you dont call your Attribute "GEOMETRY". Someone shoud create  
>> a bug report to fix this.
>>
>>> 3.  A very minor point:  You are getting LATLONG by using  
>>> CRS.decode("EPSG"4326") this is not the most efficient way of  
>>> doing it, at least for this version of uDig.  I'd suggest  
>>> DefaultGeographicCRS.WGS84.
>> Thanks for the hint.
>>
>>> Now for your question about events.  There are a few things you  
>>> have to know.
>>>
>>> 1.  Most events that are fired from feature operations will occur  
>>> in a background thread so they cannot update the UI directly.   
>>> Rather you have to run the update in the Display thread.
>>>
>>> The display thread can usually be obtained by:   
>>> PlatformUI.getWorkbench().getDisplay();
>>>
>>> Now that you have the display you can run a runnable in the  
>>> display thread using the method syncExec(runnable) or  
>>> asyncExec(runnable).
>>>
>>> 2.  To get a commit event from the FeatureStore is VERY hard right  
>>> now, although we are fixing on uDig/Geotools trunk.  So for the  
>>> commit event I would suggest listening to the EditManager.  For  
>>> the individual edit events I would listen to the FeatureSource as  
>>> you are doing.
>> Yes this helps. i will use the (a)syncExec(runnable) methods.  i  
>> used them before but i didnt remember. thanks
>>
>> Ingmar
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel



More information about the udig-devel mailing list