On Fri, 07 Nov 2008 01:59:32 +0100, Alan Grimes <[EMAIL PROTECTED]> wrote:
> > here's the biggest bug I'm seeing on my machine... > I have this simulation of my father's Harman Kardon 430 (from 1974)... > The amp works (even though it doesn't seem to for the first few > minutes... the real amp takes about 30 seconds for the input > differential amp to un-clamp... =\ > the problem is when I go to save it and load it, the entire circuit is > messed up. 2/3rds of the connectors are gone, there are a lot of > dangling junctions.... Undo/redo creates a similar effect. The problem > must be in the document heirarchy, It's all based on QT's DOM/XML engine. I'm having the same problem. Something is messed-up with se save-load (and the undo-redo?) classes. I didn't want to touch those in refactoring, because there are chanses of breaking the file structure -- that would be really annoying. Anyway, the save-load should be changed, because: - it's not extensible; there is no file-format versioning support. - it's hard to mantain: the load-save mechanism contains some "data" classes, which must be in sync with the internal data strctures. (- the generated XML sucks, imho :P) My opinion is that the code responsible for loading and saving existing file format should be separated in some classes; the objects (connectors, nodes, ...) should be able to load and save their states in some text; the versioning can be done by creating converters between the actual format and the (possibly older) other version; the conversion between document format should not be done in the components. The loading of a circuit could be something like this: - enumerat the existing known file format versions - open the file, get the version info - choose the appropriate parser for that version - that parser knows the file structure; for each contained object, calls the corresponding object's interface/constructor, for instance: var = new SomeComponent(XML_description_string); Opinions? I also found the following problems: - an infinite loop in LogicProbeData::findPos(). When the 'time' parameter is out of the range of the probe, the program gets stuck with top == bottom +1 == 1; The question is how to fix it in an 'elegant' way? - in a circuit I managed to make the digital clock to _stop_ after a few cycles. I don't know why (yet?). Zoltan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
