Re: [Shapefusion-devel] file save & fixed bug

[Etienne S. <tie...@gm...>]

2007/3/18, Tito Dal Canton <ti...@da...>:
> I was comparing files written by trunk and 0.3, just for curiosity, when
> I noticed something interesting about sequence names and something bad
> about the "minimum light intensity" fixed field.
>
> As you may know, the 32-char strings contain usually more text than
> suggested by the first length byte. These are probably residual pieces
> of longer names given by Bungie folks. Well, 0.3 won't touch them (apart
> from setting a 0 at the right location) because it keeps the full 32
> byte block in memory. Trunk, instead, will completely clear unused chars
> with zeroes, tearing off those "ancient" chars, because it converts to
> wxString internally. Not something we should worry about, just know it.
> IMO trunk behaviour is more correct, since it follows the "convert that
> ugly stuff to reasonable internal representation" phylosophy.

I see what you mean, this was because I wanted to get rid of the
wxConv stuff in ShapesEditor... Maybe we can add some debug message
when we detect something longer that what is specified...

BTW, I think this is currently broken, because you were using a value
of "macintosh", which (from what I've read in the docs) is not a valid
thing... Guess we can try fitting a nice unicode character in a
sequence name, and see what happens...

> As for minimum light intensity... Apparently numerical roundoff in
> ShapeFusion will progressively destroy minimum light intensity fields.
> I've written a small test program which takes an initial double value
> and simulates the effect of a succession of Shapes loading-saving. You
> can see the effect on the attached plot, where I've plotted the field
> value (starting from 0.5) versus the iteration. Each load-save cycle
> seems to decrease the value by 0.01! So working intensively on a Shapes
> file will eventually kill all minimum light intensities to 0. This
> severe bug seems a combined effect of our fixed-double conversion code
> (ShapesElements) and the fact that the wx field gets an event every time
> we write something to it (ShapesView). I don't have yet found how to
> solve it. Maybe we could just keep it as an integer value (between 0 and
> 0x10000) instead of converting to double. Damn wx, BTW ;-)

We could also try to use the original fixed type, because other files
uses fixed as well (I'm thinking of Sounds files, which I'm working
on...).

There are still a few things that do not seem to work correctly :
- I think we lack updating the modified state of a Shapes file (by
calling wxDocument::Modify()), because adding a bitmap doesn't enable
the Save menu item automatically.
- The wxTreeCtrl displays a strange UI behavior when browsed using
arrows. A node can be expanded by pressing 'right', but pressing
'left' is equivalent to 'up', and it doesn't shrink a node back... I
don't know if behavior is correct for you, if it's a problem with the
way arrow events are handled , or if this is, again, wx fault... (and
we need to file a bug report).
(There is a thing that I like though, that pressing left on a node
with no child takes me to its parent).
- I've had a hard time with enabling file history, and it seems it
won't work until we handle correctly file extensions.

I've started work on handling Sounds files, but I'm waiting to have
enough material to put on svn (and I'm currently away from my
computer).

tiennou