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