Fran, I tried this 3-way.
The same layer open in gvSIG, ArcView and OpenJUMP. None complained. Started editing in all the programs simultaneously, still no complaints. Start changing data and eventually a Java Heap Error and the file become corrupt. Cheers Simon Simon Cropper Botanicus Australia Pty Ltd PO Box 160, Sunshine, Victoria 3020. P: 9311 5822. M: 041 830 3437. mailto: [email protected] <mailto:[email protected]> 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: [email protected] >> <mailto:[email protected]> >> 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 >>> [email protected] >>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional >>> >>> >>> >>> >>> >> _______________________________________________ >> Gvsig_internacional mailing list >> [email protected] >> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional >> >> > _______________________________________________ > Gvsig_internacional mailing list > [email protected] > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > > > _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
