there are lots of ways to pass information between disconnected classes. if you want to create a structure or class as a container of your patch configuration, it's easily passed from the interface to the control structure to the patch routine in bin_file.
in flash_launcher, you have access to the bin_file to be written via the pointer to the control structure as control->write_bin
so if you put a public bool patch_switch_a; in bin_file.h, you could control->write_bin.patch_switch_a = true; from a button in flash_launcher.cpp
then in apply_patches() in bin_file:
if(patch_switch_a == true) {
// do stuff
}
you'd have to be careful to reinitialize them every time flash launcher is called or whatever too.
usually someone writing in c++ would also insist those are private: and have functions to set them so you have a stable api with more control over them for error checking and whatever.
here's another way which creates an isolated patch configuration class... create a new class called patch_config.
Code:
class patch_config {
public:
patch_config() {
patch_a = false;
patch_b = false;
}
bool patch_a;
bool patch_b;
}
this class could contain anything you want, integers, functions, whatever.
then maybe initialize an instance of that in datastream_control, which is practically a singleton in eehack (but doesn't have to be)
Code:
class datastream_control : public QObject {
...
private:
...
patch_config pc;
...
then in flash_launcher, you can
Code:
control->patch_a = true
then modify apply_patches() so it will take a pointer to your patch_config:
Code:
bool bin_file::apply_patches(patch_config *pc) {
if(pc->patch_a == true) then {
// apply patch a
}
}
and in flash_routine, simply call apply_patches with a pointer...
Code:
apply_patches(control->pc);
this gives bin_file direct access to the patch configuration info without breaking class isolation, you are not directly screwing around with the bin file from the flash_launcher (something i tried to avoid)
seriously, object orientation is so awesome it makes me want to gouge my god damn eyes out with a dull screwdriver.
BTW do you have some hidden write to file option for debugging left on the source. It will be nice to test patch functionality before actual burning to PCM.
yeah, bin_file itself can read/write files by path, just call that function {
...
// file ops
bool load_file(QString path);
bool save_file(QString path);
Bookmarks