Having had some queries sorted by @najdmie (Thanks), I have the next question cued for y’all.
Having added specific measurements to my ‘Individual Measurement File’ (.2mis) from different blocks from the ‘Add Known’ list, I was forced to go back at some point, because I had forgotten some needed dimension for the list.
I then discovered that the list was subsequently not reordered to accommodate the newly inserted (and out of sequence) list item.
My autistic sensibility found this disturbing, if not directly ‘offensive’, so, can this list be reordered without unnecessary expenditure of effort?
Yes and no. You can’t sort the measurement table, and you would not want to unneccsarily do so. Like everything in Seamly tools, variables and measurements are all order dependent… that is you can’t reference an item that was created after the current one. It’s all based on the use of formulas. So if we just enabled sorting on columns in SeamlyMe it would likely cause a mess for a lot of users if there are custom measurements that reference other measurments.
But…what you can do is move single measurements up or down in the table using the “move” arrows.
When you add a code, either Known or Unknown, and you would like it to appear below a certain measurement, click on the item that you want to add the code below. This way, you can place the codes as you may want them when adding them.
Another tip is to add the codes to a new file by checkmarking them in the order that you want them to be in. Every time that you add a checkmark, it will add it regardless of the code order.
Interesting… haven’t thought of that, but it makes sense as the code is probabaly appending the measurements to a temp list as you check them… then adds them to the table in the same order from the list.
Hmmm… as I’m looking at the SeamlyMe table I’m wondering is there any valid reason to be able to edit a formula for a known measurement with anything but a number value?
The reason I ask is if we were to validate the formulas for known measurements, we could then sort at least the known measurments. In fact to make it easier to code, I would add a second table for custom measurments that can’t sort. So a user could sort by name, or by group number just as they are in the database dialog.
thanks for the advice, I had found the ‘Move Up/Down’ arrows. I had assumed, prior to reading your text, that sorting and referencing the rows would have been easy enough when references to values were done by ‘pointers’ or unique keys for each row (e.g. the absolute row numbers of the 'Known Measurements Table) - this assumption comes from my time as programmer and the implementation of such techniques.
Thanks again for raising my awareness here.
PS: your subsequent remarks address, more or less what I had initially assumed for the table structure and the ease of programming references via ‘Pointers’ in the code.
Hmmm… Unless you’re a little insane (like me) and go into investigating the 8-head theory. Then you could be using things like the total_height/8*1.5.
Or if you’re investigating measurements by height & weight (again insane, like me) and you’ll be using the total_height & the Unknown weight in your formulas.
Unfortunately, doctors apparently feel justified in using it in giving medical advice, a much weightier application, (BMI.) So, at least you are saner than the majority of physicians! (& at least you don’t try applying Trigonometry to every angle. )
As a programmer you normally don’t have to worry about how to sort items - Qt handles that internally with whatever widget is being used. You simply set the sort on / off in the form or you can call the routine to sort the items in the code.
Something like this:
Altough you can programically tailor how each colum is sorted, sometimes the data does not fit the normal data model for the widget. A good example of that is how I had to subclass a sort routine to sort by color (icon) for the pattern pieces.
Not sure what you mean? I’m referring to being able to enter a formula for a known measurment with say another measurment. Which makes no sense… a person height is a person’s measured height… not a bunch of measurements added together with math functions peformed. What I’m saying - If you Add the known measurement “height” the only only chars you should be able to enter in the formula is 0-9 and the decimal point. (. or ,)
We should NOT be able to do this:
Because it can lead to this:
Which leads to us always having to explain to users WHY they can’t do that due to the dependency issues. Which was my original point of WHY the sorting is disabled in the table.
If we validate the formula field for known measurements to only accept 0.0-9.0 chars, a user could sort the known measurements any way they want.
But that’s NOT for ex: the measured value for the known measurement A01 height.
Those are “Custom” measurements NOT a “Known” measurement. If I get on the scale it tells me my weight by NUMBER… not you are: 100 lbs of water, 10 lbs of flesh, and 25 lbs of cookies. Likewise if I take a tape measure and measure my A01 height… it’s 70.5 inches - at least for the forseeable future.
What I’m getting at… in 42 years of costuming nobody has ever filled out a size sheet and filled in their height as “(nape_floor + 9) * temperature compensation”.
Ok, so of the codes with formulas are pre-set because they are half of another code. Like the I06 - Across Chest Half Front has the formula I03 - across_chest_f/2 because one normally measures the whole across chest but only works with the half measurement when drafting a pattern. These have been like this since before my time and I don’t use them.
I think it should be discussed before you change them, please.
is there a ‘Change’ process for such matters?
I would assume that Users will polled for, or warned of, such changes that may affect their respective workflows.
Well, some new users rely heavily on these “help” formulas (I know that I did) which were put there for a reason, a long time ago, and haven’t really caused much confusion in the forum. So, rather than just take something away. I think it needs to be discussed, at least, at a development team meeting and it’s usefulness assessed.
We don’t want to remove something and then need to put it back later, after we’ve changed the software to work without it.
(& at least you don’t try applying Trigonometry to every angle. 
)
Got a basic pattern like that 
