Getting parameter from dialog

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2011 at 05:58, xxxxxxxx wrote:

Oh, of course you can. 
Btw, depending on what you're doing its more comfortable to use global variables for all parts in your dialog.

  
var mod_pos, mod_ang, mod_sca;  
  
/// Dialog definitions etc ..  
  
MyDialog::Command(id,msg) {  
  mod_pos = GetCheckbox(CHK_MOD_POS);  
  mod_ang = GetCheckbox(CHK_MOD_POS);  
  mod_sca = GetCheckbox(CHK_MOD_POS);  
  
  
  
  if (id == MY_BUTTON) {      
      var doc = GetActiveDocument();  
      var op = doc->GetActiveObject();  
      if (!op) { return False; }  
  
      doc->AddUndo(UNDO_CHANGE,op);        //R12 Constant  
      if (mod_pos == true) { op->SetPosition(vector(100)); }  
      if (mod_ang == true) { op->SetRotation(vector(1.23)); }  
      if (mod_sca == true) { op->SetScale(vector(1.3)); }  
  }  
}  

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2011 at 06:04, xxxxxxxx wrote:

Thanks !  I'll try that !

Mike

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2011 at 09:24, xxxxxxxx wrote:

You can use the Get/Set methods of the GebaseDialog class. So after closing the dialog you can read out the values.

  
MyMenuPlugin::Execute(doc)  
{  
  d->Open(FALSE,-1,-1);  
    
  if (d->GetCheckbox(MY_CHECKBOX))  
  {  
      //do something  
  }  
  else  
  {  
      //do something  
  }  
}  

Please avoid global variables as much as possible.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2011 at 09:54, xxxxxxxx wrote:

This is one of those things that needs to be better documented.
There's several ways to create a plugin's structure. And they will all work. But there seems to be a certain preferred method to the madness.

What I've gathered from poking around is this:

-Init() function should only be used to set initial values
-Message() function should only be used to issue updates when something changes
-Command() function should only be used to hold GUI state code
-Execute() function is not just for opening dialogs. But also for where your main code should be placed

But then I sometimes see people put their main code inside of the main() section for dialog related scripts and plugins. Where most people just place the dialog window code.

I'd love to see an official "Maxon's preffered method for plugin structures" in the future.
right now it seems like the wild, wild, west. With everyone adding their own little twist on the plugin structures the create. And that's all very confusing to understand when you're newbie like me.

-ScottA

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2011 at 10:16, xxxxxxxx wrote:

Please avoid global variables as much as possible.

But isn't it more efficient than use GetCheckbox() etc.. more than one time ?
They actually don't have to be global if you don't need them anywhere else, but at least for the hole Command() function if you need them more than one time.

I've assumed a async-dialog.

-nux

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2011 at 17:44, xxxxxxxx wrote:

In fact this is not an async dialog.

So with the GetCheckbox() I can get a value from a closed dialog ?

Unfortunately I hadn't time to test it tonight, but there are some answers that will really help me.

I also agree that it would be very nice to have a kind of "map" from maxon explaining where and why it is better to put the main code.

Thanks all !

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2011 at 23:23, xxxxxxxx wrote:

You should have told me !
Yes, the data is stored in the object even if the dialog is closed.

I agree, too, would be very nice.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 15/03/2011 at 01:26, xxxxxxxx wrote:

Thanks again !

I can't wait to test all this tonight !

Mike

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 16/03/2011 at 05:53, xxxxxxxx wrote:

Hi again !

When I call back a Checkbox (once the dialog is closed) it always returns 0, even if it was ticked.

I'm using dialog->GetCheckbox(ID)

Any idea ?

Mike

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 16/03/2011 at 07:14, xxxxxxxx wrote:

It should work. Please post some code.

cheers,
Matthias

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 16/03/2011 at 13:46, xxxxxxxx wrote:

Hoping it'll be enough...

_
_

  
 _ptools_gui::CreateLayout()  
   {  
      var ret = LoadDialogResource(IDD_PTOOLS,PLUGIN_RES,BFH_SCALEFIT |BFV_SCALEFIT);  
      SetTitle(" P Toolbox v"+PTools_version);  
      return ret;  
    }  
  
ptools_gui::Init()   
    {  
    }  
  
ptools_gui::Command(id,msg)  
   {  
  
    switch (id)   
    {  
    case B_CANCEL:  
          Close();   
          break;  
  
    case B_OK:   
  
           Close();      
  
     default:  
  
return FALSE;   
       }  
   }  
  
  
class PTool_plug : MenuPlugin  
  {  
    public:  
  
        PTool_plug();  
  
        GetName();  
        GetID();  
        GetIcon();  
        UseMenu();  
        GetHelp();  
        Execute(doc);  
  
   }  
  
  
PTool_plug::PTool_plug()   
    {  
    super();  
    }  
  
PTool_plug::UseMenu() {return TRUE;}  
  
PTool_plug::GetName() {return "PTool";}  
  
PTool_plug::GetID() {return PLUGIN_ID;}  
  
PTool_plug::GetIcon() {return icon_map;}  
  
PTool_plug::Execute(doc)  
{  
  
dialog = new(ptools_gui);   
dialog->Open(FALSE,-1,-1);   
  
  if (dialog->GetCheckbox(P_PATH))  
  {  
      println("on");  
  }  
  else  
  {  
      println("off");  
  }  
_ _  
_ 

Thanks

Mike

Edit: sry for noobism I'll post code with indentation and tags.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 16/03/2011 at 14:08, xxxxxxxx wrote:

I'm having a look at it.

By the way, using indentation and posting the code in a [\\\code] [\\/code] Block (without \\\) would
make it much more readable.

Cheers, nux

//
You've obviosly derived your dialog class from GeDialog. Otherwise 'dialog->Open(FALSE,-1,-1)' would raise an error.
There is an additional subclass for modal dialogs. (GeModalDialog)
But I can't imagine this is the reason for the problem.

The title is set in Init(). Do never forget return values for overloaded functions, even they're blank. (For eg Init())
But couldn't figure out the real problem yet.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 16/03/2011 at 15:07, xxxxxxxx wrote:

Ok Thanks for your advices once more... I'll give a try with ModalDialog.

Mike

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 16/03/2011 at 20:58, xxxxxxxx wrote:

I'm still a learner with this plugin stuff. So take this advice with a grain of salt.
If you're wanting to get the state of the checkbox when you close the dialog window with the "OK" button. Then give this a try:

  switch (id)   
    {  
    case BUT_CANCEL:  
          Close();   
          break;  
  
    case B_OK:   
       if(dialog->GetCheckbox(P_PATH))  
         {  
          println("ON");  
         }   
       else{  
           println("Off");  
          }       
         Close();      

I've been told that switches are supposed to be used in place of if statements. And putting if's inside of switches is wrong.
However, sometimes it's necessary to use nested if statements to do things. So in this case it makes sense to me to use them together.
As I said...I'm still learning. So take this advice as something coming from a learner.

-ScottA

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 17/03/2011 at 01:34, xxxxxxxx wrote:

My goal is to be able to reach this on or off value once the dialog is closed.

This won't be enough.

Anyway, thanks ScottA

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 17/03/2011 at 07:36, xxxxxxxx wrote:

Could you solve the problem ?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 17/03/2011 at 07:48, xxxxxxxx wrote:

Is that even possible to do with a dialog?
ASFAIK. Once a dialog closes. Everything in it is deleted from  memory and can't be accessed until the dialog is opened again.

My understanding is the only way to store things is by using a tag plugin. Since the tag is always there. It can be used to hold a value(in this case a state value). And you can even make tag's invisible to use them as hidden storage containers.
But I could be wrong.....

-ScottA