On Sun, Jan 18, 2009 at 3:35 PM, Sean M. Pappalardo <[email protected]> wrote: > Hello. > > Albert Santoni wrote: >> // Construct row in table >> addRow(device, group, key, controltype, miditype, midino, midichan, >> option); >> >> You basically need to pass the information in those parameters back from >> MidiMapping somehow. Perhaps that information should be contained in a > > Exactly, so I made a QHash (since all those parameters are QStrings > anyway) keying on the parameter names like so: > > QHash<QString, QString> parameter; > parameter["device"]=device; > parameter["midino"]=midino; > ... > > ...and so on for each parameter. Then I just pile each QHash (for each > addRow call) onto a QList. Then dlgprefmidibindings calls > getParameterList() which returns a reference to that QList, which > dlgprefmidibinding can use to then pull off each QHash in turn and call > addRow(parameter["device"], parameter["midino"], etc.) until the list is > empty. > > While that may not be the best way to do it, it's compact for > transmission between objects and QHashes are supposed to be pretty > efficient. I also made sure to delete the QLists when I'm done with them > (via MidiMapping::deleteRowParams() which gets called from > dlgprefmidibindings after it's done with the QLists.) > > Sound reasonable?
I don't really know what's going on but: why are you changing the list?! Make the list once, keep it in place. Keeping data static when you can avoids the entire class of bugs that dealing with state in multiple places brings. >> been struggling with conceptually with the MIDI code. The XML is both >> the data structure in which the MIDI mappings are stored at runtime as >> well as a natural format for serialization. > > Not in Tom's code, at least. It keeps an internal QTableWidget called > tblBindings which it modifies during runtime user manipulation. After > the user clicks OK or save or whatever does it call BuildDomElement() to > make an XML file out of that internal table. I've just moved the XML > creation (and loading) code to MidiMapping. (There's still some left in > BuildDomElement but that's because it needs access to many of the > internal variables, specifically tblBindings. But it now calls > MidiMapping's addControl/addOutput function to actually add it to the file.) > > So once I get this stuff working, you all might want to have a look at > further cleanup. > >> your codebase with XML parsing crap everywhere. Instead of going >> structFoobar->midi_note, you have to walk through this XML tree. > > That's probably more elegant that a QHash, but it's only needed one time > on XML loading and can be deleted after that. > > ----- > > All that said, I'm trying to compile the monster and getting a series of > errors I can't figure out. (And I've learned from past experience that I > need to fix the error at the top of the list before worrying about any > others since they can all change.) > > So I'm getting this: > src/script/midiscriptengine.h:47: error: 'MidiCategory' has not been > declared > > line 47 is this: > bool execute(QString function, char channel, QString device, char > control, char value, MidiCategory category); > > But that file #includes midiobject.h where the typedef enum MidiCategory > is defined. (If I copy that typedef block to midiscriptengine.h, it > complains that it's already defined!) > > What shall I do? (Short of replacing those parameters with another > QList<QHash> :) ) Don't you have to say bool execute(QString function, char channel, QString device, char control, char value, enum MidiCategory category); ? -Nick ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
