Wizards update

[cncdrive]

Hi Dan,

It's up to you what you return from the informplugin function and how you handle the returned value in the caller macro or plugin.
If you don't want to raturn anything then you can return null and you do not even have to handle it in the caller function.

The idea behind the return object is that you could send any type of data to a plugin and it can use that data and can return another data.
For example you can send a string like:

string mydata = "hey!";
exec.Informplugin("myplugin.dll", (object)mydata);

And in the receiver plugin you can do a return null.
Or you can return another object if needed like: return (object)newdata;
And then you can test the return type in the caller function with:

object newdata = exec.Informplugin("myplugin.dll", (object)mydata);
if (newdata is string)
{
string returnedstring = newdata as string;
//Do something with the string...
}

This was ofcourse just an example when the data object is string type, but it could be other types too. This is why we used the generic object type as parameter and as return types, because this way you are not limited in what object type you sending and returning.

[dezsoe]

Hi Dan, Could you compile me a version without the onscreen check, so I could test the Callbutton problem?

[Dan911]

Hi Dan, Could you compile me a version without the onscreen check, so I could test the Callbutton problem?

Sure, take note when opened with callbutton that Cut or pocket a circle wizard works(form2) and all others you will get the STAthread exemption. I can use any wizard with form2.

This also has the informplugins event in it. If you replace CallButton(6333) in macro with....

Code: Select all

string button = "6333";
exec.Informplugins((object)button);


You will see it eliminates the problem, thanks for taking a look.

Dan

***Edit***

LOL... forgot to upload

Dezsoe.zip

(118.01 KiB) Downloaded 1734 times

[cncdrive]

Hi Dan,

The exeption is probably because you are in another thread and trying to invoke a form element.
E.g. in Windows programming if you will try to set the value of a label on the screen from anything other than the UI thread then you can randomly get an exception like that.
To avoid this problem do not update Form items from other than the UI thread.
You can Invoke your Form with a function, like:

Code: Select all

myform.Invoke(new MethodInvoker(() => Myfunction()));

The invoke will make your caller thread to wait until the called function returns and you will not get an illegal cross thread exception.
Or you could use BeginInvoke instead of Invoke in case you don't want the caller thread to wait for your function to return.

And you can always check the SynchronizationContext.Current variable value to see if you are in the UI thread with your code or not.
The value is null if you are not in the UI thread but in a different thread.

[dezsoe]

Thanks! I've just wanted to ask for the file...

[Dan911]

Hi Dan,

The exeption is probably because you are in another thread and trying to invoke a form element.
E.g. in Windows programming if you will try to set the value of a label on the screen from anything other than the UI thread then you can randomly get an exception like that.
To avoid this problem do not update Form items from other than the UI thread.
You can Invoke your Form with a function, like:

Code: Select all

myform.Invoke(new MethodInvoker(() => Myfunction()));

The invoke will make your caller thread to wait until the called function returns and you will not get an illegal cross thread exception.
Or you could use BeginInvoke instead of Invoke in case you don't want the caller thread to wait for your function to return.

And you can always check the SynchronizationContext.Current variable value to see if you are in the UI thread with your code or not.
The value is null if you are not in the UI thread but in a different thread.

Thanks Balázs for the point in direction, I would certainly prefer to find my error than using a work around. I am definitely in another thread when invoking the new form.
I guess calling from GUI is less sensitive to my error than the Macro Class. I will definitely report back if a find a solution and exactly what caused it.

Thanks again,
Dan

[dezsoe]

Hi Dan, A quick solution (I had no time to check the file you attached yet) can be to call the standard showup function for the plugin itself from the Buttonpress_event:

Code: Select all

UC.Pluginshowup("Wizards.dll");


[Dan911]

Finally figured out what this problem was...

Just to refresh the Wizard plugin had no problems opening from an onscreen button or hotkey, but when opened from macro with Callbutton() some of the wizards would cause a STA exemption.

The culprit was some of the combobox's AutoCompleteSource property was set to ListItems. I guess that's one of the disadvantages of copy/paste. Very Happy I can now add to my Macro Menu Button plugin, I will update for anyone interested.

Dan