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

Tue Jan 12 13:41:08 CET 2010

Fran,

Your answer makes sense. Thanks for the feedback.

Yes, I occasionally sleep but since you guys are awake in Spain when it 
is night in Australia, if I need quick answers I need to regularly check 
my email and reply to any queries promptly.

As I have alluded to before, there are not many experienced gvSIG users 
on this side of the globe so I am pushing hard to become familiar with 
the program so I can use gvSIG in my normal working activities and maybe 
help other along the way.

You mentions Version 2; is it expected this problem will be solved in 
this version or is it that the underlying architecture is changing and 
minor adjustments to version 1.9 will be a waste of time?

If version 2 will not fix the problem directly maybe a programmatic 
solution would be to (a) check the project for other instances of the 
file when requested to make changes and refuse permission to edit unless 
these are removed, or (b) deactivate all other instances, release the 
files and open the file to be edited exclusively; if you can't gain 
exclusive access refuse access to the file. I presume Java can lock 
files preventing others from using them, check if a file is already 
locked, etc. Not true multi-user  solutions but at least prevents what 
is common practice in other programs causing a system crash (with no 
real clear idea why).

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 9:20 PM, Francisco José Peñarrubia wrote:
> 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
>>
>>      
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>
>
>    