Hola, vengo con otro inconveniente. Cuando abro el SeamlyMe para modificar una medida aparece ese error critico
la version de seamly que tengo es la que dieron en el forum
Agradezco su ayuda
Hola, vengo con otro inconveniente. Cuando abro el SeamlyMe para modificar una medida aparece ese error critico
la version de seamly que tengo es la que dieron en el forum
Agradezco su ayuda
¿Se trata de un archivo de medición de Clo3D? O eso, o puede ser un archivo .vit/vst antiguo.
Puedes editar el archivo en un editor de texto o enviƔrmelo para repararlo.
No⦠the error indicates trring to open a newer ME file in an older version of SeamlyMe.
It was an old .vit file on a newer version of Seamly.
Or trying to open a vit / vst file that was made in Tape after the fork.
You can open older vit files in SeamlyMe⦠it will convert⦠you canāt open newer files in an older app. That what the Error message indicates. The version of SeamlyMe being used could only open a max schema of 0.3.3. Our current schema is 0.3.4. User needs to udate the apps.
Yes, I sent her the link to download the latest.
I think we should update the max version warnings for 2D & Me to something that makes more sense. The messages are not clear to the user that they need to open the file in a newer version of the app.
As a side note itās something we need to be aware of if we fix a userās file⦠we canāt send them back a newer ver of the file. Personally I like having the ver in the filename. If I were to see MyMeasurements_v033.smis⦠I would know right away I canāt send a user back MyMeasurements_v034.smis. Thatās precisely why we write a backup file with the version suffix when a file gets converted to a newer verion when loading.
Yes, itās a problem. I thought a person could still open the old .vit files and then Save As, but thatās no longer working.
Is there a way to set it so that it deletes the v033 after the file has been saved as v034?
You can still open older vit files⦠but not a vit that has been written in Valentina after the fork with a version greater than that at the time of the fork. Which probably was v0.3.3. i.e. We can canāt open a v0.3.4 vit file as it doesnāt exist in the SeamlyMe schema.
This will open in SeamlyMe:
This would not:
As the SeamlyMe now checks for the < smis > tag for files newer than < version >0.3.3< /version >
In other words⦠the file format diverges with version 0.3.4.
Why? Itās a backup (copy) file⦠not a temp file. Itās there in case for whatever reason - a bug in converting? - you can go back to the orgininal ver. If youāre just going to delete it, thereās no reason to write it.
Think about it in context of the save name template thing that was being discussed recently. Most people are not as intimately familiar with the current schema version as you are, so if the file is being saved with the schema version noted in the filename, it would be nice to have it automatically update when the schema version advances.
At least Iām pretty sure thatās the angle @Grace is speaking from.
t would be nice to have it automatically update when the schema version advances.
Right⦠but you may stll want a backup of the old schema ver when converting. Has nothing to do with whether I know the schema any better. Personally I think we need to have versioned backups like I did with the feature I lost on the crashed hardrive. Saving a backup during conversion was all part of that. And if you recall part of the backup feature I worked out had a limit of backups - you donāt want the conversion backups - uncheck save backups or set the limit to zero.
Plus Iām all for having an āoptionā to append the schema ver to saved filenames⦠regardless of whether youāre just saving or itās a conversion. It just has to be smart enough so we donāt end up recursive names like MyMeasurements_v032_v033_v034.smis
Yes, my concern is as @Pneumarian says. Most people want only 1 copy of the measurement file on their computers so that they canāt get confused as to which one they need to open, and so that they donāt end up with 10 copies of the same file and then they end up deleting the one that actually works. Itās different for devs that may wish to see the versions but most people just donāt think of things like that, they think that a version is what they add to the name of the file when they make changes to it.
I agree that saving a conversion from .vit/vst to .smis/smms should keep the old .vit/vst file for a while and the .vit/vst should be manually deleted later, once the new version is proven to be working and sound.
We can canāt open a v0.3.4 vit file as it doesnāt exist in the SeamlyMe schema.
Ah! Ok, that makes sense. Thank you. A lot of people went with Valentina for a while and then switched to Seamly later. It was a confusing time.
Itās different for devs that may wish to see the versions but most people just donāt think of things like that, they think that a version is what they add to the name of the file when they make changes to it.
Again⦠having a backup has nothing to do with devs. It has to do with having a previous copy of a file you may need to fall back on. If I updated the schema and due to a bug it started to mangle all your measurement or pattern files when converting - then you would asking if we could have backup files. The ver schema is appended to conversion backups for the very reason of identifying it as an older version.
Having backups and autosave is a common ābest practiceā with many software applications.
That being said ⦠if you donāt want the backups - thereās the Prefs option I already added about a year ago:
Plus I also made it so the apps will only make 1 conversion backup if it doesnāt already exist so you donāt end up with mymeasurments_v033.smis, mymeasurments(1)_v033.smis, mymeasurments(2)_v033.smis, mymeasurments(3)_v033.smis⦠like it use to.