🚀 go-pugleaf

Currently, there's macros to make a field selection callback class &
file selection callback class, e.g., from a recent posting

    declareFieldEditorCallback(PrintIt)
    implementFieldEditorCallback(PrintIt)
    
    void PrintIt::accept(FieldEditor* e) {
        if (e != nil) {
    	printf("accept: %s\n", e->text()->string());
        }
    }
    
    void PrintIt::cancel(FieldEditor* e) {
        if (e != nil) {
    	printf("cancel: %s\n", e->text()->string());
        }
    }
    


However, I've found it easier to just specify the class w/o the generics...


  class SelectFileAction : public FileChooserAction {
  public:
      virtual void execute(FileChooser*, boolean);
  };
  
  void
  SelectFileAction::execute(FileChooser* e, boolean ok)
  {
      printf("In file chooser action\n");
      if (ok) {
  	cout << "Accept " << e -> selected() -> string() << "\n"; 
      }
  }
  

The only problem is, I'd like to be able to use MI to do the same
thing. E.g., lets say I have a Glyph with represents some dialog
w/many call backs. I could inheriet from each of them & then pass one
pointer for all of the call backs.

But, if they all use the same ``callback procedure names'' (i.e. like
execute, above) then this won't work.


Therefore, I propose that the callback procedure names be more
specific. This would let me do something like...

  class MyDialog : public Dialog,
		   public FileChooserAction,
		   public FieldEditorAction
	 {
  public:
      virtual void execute_filechooser(FileChooser*, boolean);
      virtual void execute_fieldeditor(FieldEditor*, boolean);
  };


Granted, there's a move away from using virtual MI classes, but this
is will still work with the existing framework & allow the virtual MI
stuff when people get their compilers working.