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?
> 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> :) )
Sean
<<--------------------------------------------------------------------------------->>
This E-Mail message has been scanned for viruses
and cleared by >>SmartMail<< from Smarter Technology, Inc.
<<--------------------------------------------------------------------------------->>
------------------------------------------------------------------------------
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
