Export to csv of measurement

IMO What it should be is @Measurement_1, @Measurement_2, etc in the name column and CM1, CM2, etc in the number… where the name is editable and the number not - for creating new patterns. For existing patterns, the number would still be na as we can’t generate a new unique number. The name can’t be “na” as that is the name variable used in formulas.

1 Like

:smile: I knew you would figure out the proper way :grin:

Well… I looked at what we could do here. I can easily change the default custom measurment name to something more descriptive than @M… like I suggested @Measurement_1, @Measurement_2, and based on that name create a Number CM1, CM2 - I’m thinking CM for custom measurment, and we have to avoid the existing M1 for the known measurements - a problem may arise when you edit the name assuming one would rename the default @Measurement_1 to something more descriptive - AND IF the routine that checks if the name is “unique” in the data container recycles the “_1”. Since the number for the knownm measurements is just deduced from the diagram name, it’s not contained in the data container… so without adding a bunch of code to add the Number as a variable for the custom measurments to the data container, the “Number” CM_1 will start to repeat as a name is edited. If you entered all the new Custom measurments first, then edited the names, there would be no problem. I also would not want to make the CM number editable, as that opens up another way for duplicate (or non sensical) numbers.

It’s possible I could take an easier approach by basing a unique CM’s on what’s already in the Number column of the table.

1 Like

Oh, dear! This explains a lot to me. I didn’t realise that the number is only a diagram name. I was looking at it in the way a database works where you have a short reference number and then a name and the diagram and other information. So the number is the container that is holding all the information together.

Seen in this light, the na is fine, it’s really not a biggy. It was more to use those numbers to sort in the Excel sheet so that one can have the numbers in the order of Known numbers so that it’s quick to go down the list and add them and then have the Custom items at the end or the beginning for adding separately (if they’re somewhere in the middle, I can just skip over them).

I normally add other numbers so that I can sort them back into the order in the patternmaking system book once I’m done.

I’m so sorry to put you through all this :sleepy:

No. There is a data container for a pattern / measurements that’s created when a pattern / measurement file is loaded, and is added or deleted from as you work on a pattern. One of the pieces of “cariable” data is the Custom Measurement name. Since names are stored in the data container, we can search to see if a name exists ( like @M-1), if it does, increment the number so we have unique nanes. Well, like I said the “Number” is simply based on the diagram number for Known Measurements, and are not stored in the data container. So without making the Number column fields a data container variable, there’s an issue basing the number on the @M_1, @M_2, etc as I have the feeling that if you edit @M_1, the next new custom measurement becomes @M_1… and thus we’d have multiple CM1’s… unless I can use the data in the Number Column instead if the data container to find a unique number.

1 Like

Not a big deal. Kinda forces me to look at the ME code more closely which I haven’t paid as much attention to.

1 Like