From what I can tell, LoadPackagePreferences without the /MIS flag will set V_flag<0 AND throw a dialog error notice if the preference file is not the same size as what was saved. However, with the /MIS=1 flag, V_flag is set to zero, no dialog error notice is thrown, and the preference file is "force read". Useful would be to have a /Z flag that will bypass the dialog error notice, not read the preference file, and maintain the state of V_flag<0 as a signal for the error to be handled internally (perhaps still setting V_bytesread to the file length anyway).
Since you know how many bytes you asked for and you know how many bytes were read (via V_byteRead), you can detect the situation where the file is larger than you expect. So I don't see the need for a new /MIS mode.
Since you know how many bytes you asked for and you know how many bytes were read (via V_byteRead), you can detect the situation where the file is larger than you expect. So I don't see the need for a new /MIS mode.
I had to find an OLD preference file save command, save the preference file, try to reload it using the new loader, and figure out the difference in byte counts between the two. I was hoping to use a LoadPackagePreferences/Z flag to give me a silent notice of a mismatch in byte counts without having to do all this computation.
Perhaps then an equivalent request: Does a function exist that will compute the byte count of a structure, ie ...
I had to find an OLD preference file save command, save the preference file, try to reload it using the new loader, and figure out the difference in byte counts between the two. I was hoping to use a LoadPackagePreferences/Z flag to give me a silent notice of a mismatch in byte counts without having to do all this computation.
Quote:
Does a function exist that will compute the byte count of a structure
No.
Quote:
I had to find an OLD preference file save command, save the preference file, try to reload it using the new loader, and figure out the difference in byte counts between the two.
What are you doing with the difference? I'm not sure what good that does you.
If you are trying to create a new preference structure and yet be backward compatible, I think you should give the new structure a new name. If the new structure does not exist in preferences, try to read the old structure and copy it to a new structure.
When I define a preferences structure, I put a version field as the first field and I leave a lot of reserved fields at the end. This allows changing the structure while still supporting old preferences.
What are you doing with the difference? I'm not sure what good that does you.
I needed the byte count of the old preference file so that I could do a test as to whether it was the same as the new preference file. I had no clue about the value of either. My code now checks whether the byte size of the preference file is different from the old version and if not, handles accordingly.
hrodstein wrote:
If you are trying to create a new preference structure and yet be backward compatible, I think you should give the new structure a new name. If the new structure does not exist in preferences, try to read the old structure and copy it to a new structure.
Had not thought of doing this. That might be what I will do at the next update.
hrodstein wrote:
When I define a preferences structure, I put a version field as the first field and I leave a lot of reserved fields at the end. This allows changing the structure while still supporting old preferences.
Versioning the preference structure is definitely the next thing I will do.
I don't have a real strong feel for padding it at the end though. In the recent iteration, for example, I changed the length of a unchar that was in the middle of the structure to make it a unchar "array". I guess that would mean decreasing the size of the reserved field at the end of the structure. However, I imagine I would have to figure by how many bytes my new structure has increased, and then map bytes to appropriate sizes of all the variables in the structure. And then determine ... do the parameters shift positions accordingly, or do I need a dummy pad byte???? In my younger days doing Trash-80 assembly coding, I might have been able to do all this in my head (in hex as well). Now, I'd just rather have a LoadPackagePreferences/Z flag or a GetByteSize(structure) function to cover my sloppiness. :-)
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
I needed the byte count of the old preference file so that I could do a test as to whether it was the same as the new preference file. I had no clue about the value of either.
I think I finally see your point. LoadPackagePreferences/MIS=0 does not tell you if you loaded everything or not. I have made a note in our wish list.
You can determine if there is a mismatch like this:
Also, I thought of a skanky way to know the size of a structure. Call StructPut /S to store the structure in a string and then call strlen on the string.
July 21, 2010 at 09:23 am - Permalink
I had to find an OLD preference file save command, save the preference file, try to reload it using the new loader, and figure out the difference in byte counts between the two. I was hoping to use a LoadPackagePreferences/Z flag to give me a silent notice of a mismatch in byte counts without having to do all this computation.
Perhaps then an equivalent request: Does a function exist that will compute the byte count of a structure, ie ...
if (V_byteRead != currByteCount)
...
endif
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
July 21, 2010 at 10:40 am - Permalink
No.
What are you doing with the difference? I'm not sure what good that does you.
If you are trying to create a new preference structure and yet be backward compatible, I think you should give the new structure a new name. If the new structure does not exist in preferences, try to read the old structure and copy it to a new structure.
When I define a preferences structure, I put a version field as the first field and I leave a lot of reserved fields at the end. This allows changing the structure while still supporting old preferences.
July 22, 2010 at 03:45 pm - Permalink
I needed the byte count of the old preference file so that I could do a test as to whether it was the same as the new preference file. I had no clue about the value of either. My code now checks whether the byte size of the preference file is different from the old version and if not, handles accordingly.
Had not thought of doing this. That might be what I will do at the next update.
Versioning the preference structure is definitely the next thing I will do.
I don't have a real strong feel for padding it at the end though. In the recent iteration, for example, I changed the length of a unchar that was in the middle of the structure to make it a unchar "array". I guess that would mean decreasing the size of the reserved field at the end of the structure. However, I imagine I would have to figure by how many bytes my new structure has increased, and then map bytes to appropriate sizes of all the variables in the structure. And then determine ... do the parameters shift positions accordingly, or do I need a dummy pad byte???? In my younger days doing Trash-80 assembly coding, I might have been able to do all this in my head (in hex as well). Now, I'd just rather have a LoadPackagePreferences/Z flag or a GetByteSize(structure) function to cover my sloppiness. :-)
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
July 22, 2010 at 06:59 pm - Permalink
I think I finally see your point. LoadPackagePreferences/MIS=0 does not tell you if you loaded everything or not. I have made a note in our wish list.
You can determine if there is a mismatch like this:
if (GetRTError(1)) // Clear error
Code to handle error
endif
Also, I thought of a skanky way to know the size of a structure. Call StructPut /S to store the structure in a string and then call strlen on the string.
July 22, 2010 at 10:31 pm - Permalink
Thank you. That will do wonderfully.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
July 23, 2010 at 03:26 am - Permalink