[Gvsig_english] QUESTION gvSIG 1.9 (BN 1253) -- Hoes does gvSIG reference shapefiles in ToC

[Francisco José Peñarrubia]

Hi Simon.

I'm wondering if you sleep some time.... ;-)

I mean: to workarround the problem (yes, it can be seen as a bug), you 
shouldn't edit a shape file (or another layer like PostGIS) if you have 
more than one instance in your view (or in another view). Even I would 
say if other person is reading this file, he will have problems.
gvSIG can edit, and is intended to use to that, but is not prepared 
(yet) to be a concurrent editor.

About adding fields and drivers autonomy.... It depends if the driver is 
opening-reading-closing all the time, which is a time consuming task. 
The driver may not read always the number of records, or use some 
buffering that will not be synchronized with the other drivers. That's 
why you will end with Java Heap crashes. Maybe the solution can be to 
use the same driver object, but these things will change in 2.0 release, 
so, I think we cannot dedicate more time to this issue. That's why I 
suggested the workarround.

Best regards.

PS: About concurrent modification and multi user editing, I have some 
old ideas to develop, but honestly, I don't have time for now.

Fran Peñarrubia
gvSIG Team


Simon Cropper (Botanicus Australia Pty Ltd) escribió:
> Fran,
>
> "So, you shouldn't edit your file [2], and about names, you can change manually the name of the layer. Maybe some errors will disappear then [1]."
>
>     [1] I tested having all the names the same and different. This is
>     not a problem. The trigger appears to relate to symbology and
>     labeling when two instances of the same shapefile are in the ToC.
>
>     [2] How can you "not edit a file" in gvSIG, isn't this what it is
>     for? If having multiple instances in the ToC causes a crash then
>     this is a bug.
>
>
> "If you edit one of them [3], the others will not be aware of changes, and the application will crash."
>
>     [3] If you add a field in one instance, it appears in the other
>     instances, so the drivers can't be that autonomous.
>
> I will watch this behaviour and report it as a bug once I can pin down the causal factor.
>
> Cheers Simon
>
> Simon Cropper
> Botanicus Australia Pty Ltd
> PO Box 160, Sunshine, Victoria 3020.
> P: 9311 5822. M: 041 830 3437.
> mailto: scropper at botanicusaustralia.com.au 
> <mailto:scropper at botanicusaustralia.com.au>
> web: www.botanicusaustralia.com.au <http://www.botanicusaustralia.com.au>
>
>
> On 12/01/2010 8:19 PM, Francisco José Peñarrubia wrote:
>   
>> Hi Simon.
>>
>> Yes, I think so.
>>
>> If you have multiple shp files in TOC, each one will have its own driver
>> reading from the .shp, .shx, .dbf files. If you edit one of them, the
>> others will not be aware of changes, and the application will crash.
>> So, you shouldn't edit your file, and about names, you can change
>> manually the name of the layer. Maybe some errors will desappear then.
>>
>> BTW, I sow (among many others ;-) ) some mails about FrameViews in a
>> Layout. (Some FrameViews referring to the same View in the same Layout).
>> I did some tests and I agree there are many bizarre behaviours, but I
>> wonder if you are using the tools
>>
>>
>>
>> to position your ViewFrame from the Layout window. They are activated
>> when you select your ViewFrame.
>>
>> To summarize: If I remember to ALWAYS (it's a bug) select the right View
>> in the combo from Properties and uncheck Active Link and select Mantain
>> View Scale, it seems it works well. (Any other combination don't work
>> well and we should revise it).
>>
>> Thanks for your time, and keep going.
>>
>> Fran
>>
>> Simon Cropper (Botanicus Australia Pty Ltd) escribió:
>>    
>>     
>>> Hi,
>>>
>>> When you have multiple instances of the same shapefile in the Table of
>>> Contents how does gvSIG know which your are referencing with the
>>> extensions or plug-ins?
>>>
>>> I presume it would need to be as "ToC layer #1", "ToC layer #2", "ToC
>>> layer #3" rather than referencing by name as the ToC allows you to add
>>> multiple instances of the same shapefile.
>>>
>>> I have had a lot of java heap errors since presenting multiple instances
>>> of the same shapefile in the ToC and creating separate labeling and
>>> symbology for each. I suspect that some subroutines don't explicitly
>>> reference the ToC list but rather the file name if that is possible.
>>> Crashes appear to centre around labeling and symbology issues. One wierd
>>> thing I have noted is the propensity of the "other values" option keeps
>>> reappearing even though I have it unchecked - particularly if I edit a
>>> file. That is, "other values" will be unchecked but when I edit the
>>> shapefile it reappears.
>>>
>>> The question then is "Could the presence of multiple instances of the
>>> same file in the ToC, each with differing labeling and symbology, cause
>>> a memory leek?"
>>>
>>>      
>>>       
>> _______________________________________________
>> Gvsig_internacional mailing list
>> Gvsig_internacional at listserv.gva.es
>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>>
>>
>>    
>>     
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>