this is a re-posting (edited, for the children.) of an unanswered e-mail to Tom dated 03May2007, as the requested continuation of [thread=3820]thread 3820[/thread].
upon my recent reencounter, i raise the issue again, as i continue to find an increasing need for well-structured UserNumbers that can accomodate, while self-describing, ever-growing rigs and the "phantom fixtures" that join them to provide a logically divisible layout for programming against the effects engine.
... that, and this is just... beyond scary...
[quote=quinn]
I saw the sign:
[ATTACH]692[/ATTACH]
Clearly, Views are being sorted against their numbers’ signed values.
There’s another problem with sorting: when 0 exists, 32768 will always be at index 0, whether sorted ASC or DESC.
[ATTACH]692[/ATTACH][ATTACH]693[/ATTACH]
So i’m thinking to myself, “great! UI bug! No biggie.”
But then I started playing around.
Results of Recording Items 32767, 32768, 32769, 65534, 65535, 65536, 0:
(page 0 didn’t make it into the picture)
[ATTACH]694[/ATTACH]
This is interesting for a whole bunch o reasons:
Numeric Limits
When the target number is between signed maxvalue and unsigned maxvalue, absolutely nothing happens!
Unless it’s a Page, View, or List!
Even though 32768 is painted when we’re not Showing Fewer Buttons
When the target number is greater than unsigned’s maxvalue, item 0.5 happens (followed by 0.8, 0.9,...,0.9999, error in tasks)
Unless it’s a Page!
Sorting
While the 65534’s are not legitimate values for sorting, they’re still displayed as 65534!!!
The Views sheet exhibits the order-by-signed-with-32768-always-on-top behavior, but the Lists sheet orders DESC correctly!!!
So what about patch? Patch gives me a msgbox telling me not to use usernumbers > 99999... but...
an attachment has been removed from this post due to the forum's 10-attachment-per-post limit. in it, the Fixture Window shows the original User Numbers 1-10, and the Programmer shows 1 > 10 @ 1 > 10 to establish a reference to the original User Numbers and the Fixture Numbers, which persist.
[ATTACH]695[/ATTACH][ATTACH]696[/ATTACH][ATTACH]697[/ATTACH]
Again, a small UI problem.
But the real kicker’s the Command Line parser:
Again Record Position 65535.
Again Record View 65535.
Again Record List 65535.
Record List 65535/2.
[ATTACH]698[/ATTACH][ATTACH]699[/ATTACH][ATTACH]700[/ATTACH][ATTACH]701[/ATTACH]
And that’s where I just about died.
At first, I really felt for whoever has to deal with Qt. cuz it ain’t pretty. I know.
But then I put the errors coming (or...not...coming...) from tasks, together with the... mutilations... I saw in the command line, and realized that I’m lookin at more of a major design flaw than a simple UI issue.
Item Numbers.
They’re so incredibly basic.
But different parts of III seem to interpret, handle, and (probably even) store them in totally different ways.
In my head there’s a class DirectoryNumber, with these features:
Integral
Fractional
Comparison Operator Overloads
.ToString()From what I’ve seen, either
There’s not a defined DirectoryNumber, or,
The DirectoryNumber is disregarded and ignored at will
So *why* then, are the following statements true?
Items can sometimes be > 32767
“tasks” has *different* ways of evaluating whether a target number is valid
“tasks” handles invalid target numbers differently
Sometimes doing nothing
Sometimes recording 0.5
Sometimes straight abend-ing
UI classes!!!!!!! Ahhhhhhhhhh!!!!!!! have the responsibility of evaluating (65534.1234
And the evaluation methods aren’t inherited!!!!!!!! Grr!!!!
Sometimes evaluated by *signed, sometimes evaluated by *unsigned
Lists evaluate differently than Views
Lists evaluate differently by ORDER BY
ASC: (65534.1234
DESC: (65534.1234
Table views display numbers differently
Programmer can display completely wrong info. IT’S OVERFLOWING!!! AND SOMEONE’S HANDLING IT!!! WRONGLY!!!
Ok, fine, that one’s a little different cuz usernum’s can go to 99999 and don’t have .1234. but that still shows that UI parses the numbers differently than “tasks” which I’m sure is copy/paste of how “...DmxSpitterOuter...” does it, which is different than.......... there’s still no instantiation of a common, declared construct. (or, its use is not being enforced)
Record List 65535 yields Record Choose
????? When did Choose become a NUMBER???
I’m guessing it’s -1, of course. Cuz why not. But still. How do you get an enum out of a DirectoryNumber???
So instead of praying for XYZ, I’m now praying that your branches are cleaner than your object models.
