Yes, this is the behaviour I supposed. Your idea about looking better to the file and test if it can be "real" editable make sense, and maybe done with a few lines of code. Maybe we can fix this, if testing people agree.
Come on, go sleep ;-) Fran. Simon Cropper (Botanicus Australia Pty Ltd) escribió: > 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 > _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
