Problems using constructor and distructor to save current...

[Robertspark]

The probably of a conflict is relatively low for a shared variable, is it not?

First you can choose to use any variable from a fair range, and then you have a fairly large number base that you could use as a variable

[ger21]

Ger do you fill the same way about the controllers at work ???

The machines I use at work have custom controls, and while complex, are actually pretty basic. They don't need any customization, and don't really allow it.

Yes, 95% just want to run there machines, and most don't need any customization at all. Other pay me to do it.

In the past, DIY was the only option. Now there are a lot of options to get up and running quickly.

The probably of a conflict is relatively low for a shared variable, is it not?

I used ONE in my screenset, and was informed that it was in conflict with the AutoLeveler plugin, which iirc, uses 100 or more vars.

[dezsoe]

That's why I never use #variables to store any data, and the IDs of all of my custom fields and LEDs are stored in the profile, so they can be changed in minutes to resolve a field/LED number collision. (This would also be true for checkboxes and lists, but I never use them.)

[ger21]

Yes, for the people doing the customization, conflicts are easy to resolve.
For people downloading various plugins and macros, not so much.

With UCCNC, you also probably won't have a million different screens to choose from like Mach3 users had. While it's easy to create a screen, or modify for your own use, it's a lot more work supporting all the various motion controllers.

[kig23]

I'm sorry I lost some posts. The code I proposed requires a change. Here is the code.

Code: Select all

new Thread(delegate () {
    ChangeCurrTool ();
   }).Start();

#Events

private void ChangeCurrTool ()
{
   while (AS3.GetLED (25));
   Thread.Sleep (500);
   
   try
   {
      exec.Setcurrenttool (Convert.ToInt32 (exec.Readkey ("MyCNC", "CurrentTool", "False")));
   }
   catch ()
   {
      // do something to handle the exception
   }
}


Nice! But, instead of "False" use "0", because "False" cannot be converted to Int32.

You're right Dezsoe, that "False" will raise un exception, but in this case is better to get exception and handle it with try-catch block. You will know that the constructor macro doesn't load the current tool value, rather than having the default value 0.

[dezsoe]

Yes, that's another point of view. If I want to hanle the problem, I set default to -1 and check it. But, both work!

[kig23]

Thanks Dezsoe for sharing your opinion.

[kig23]

I migrated from Mach3 to UCCNC one month and a half ago. Maybe you already know it, but i found that if the value of a key in the .pro file is missing that will raise an exception. Only if in the .pro file is missing the key the Readkey () will get the default value. This was the reason to decide the use of exception handling. Normally I also prefer to avoid the use of exception handling.

[cncdrive]

The exec.Readkey function does not raise an exception if the key to be read is missing.
Why you getting an exception with your code is because you reading a key and giving it a default value "False".
If the key is missing then the Readkey function will return this default "False" value, but you also converting the return value of the Readkey function to an Int32 type,
but the False value is boolean and is not a valid value for Int32 type. So, the Convert.ToInt32 function will raise the exception when it can't convert the returned False value to an Integer number.
You should change the default value to a number, e.g. to "0" instead of "False", if you don't want to receive an exception.

[kig23]

Thanks for your replay.
I know that if you try to convert bool to int this will raise an exception. But the point is other. Maybe i didn't express myself well. I wrote:

if the value of a key in the .pro file is missing that will raise an exception

i'm referring to the following situation. I've got a strange issue that UCCNC sometimes cancels the value of the key in the .pro file, not that the key is missing. When i opened the Default.pro file i found that the value of the key (CurrentTool ) is missing, like the following code.

Code: Select all

[MyCNC]
CurrentTool=


When i try to start UCCNC and read the key with the following code in constructor macro:

Code: Select all

new Thread(delegate () {
    LoadCurrToolValue ();
   }).Start();

#Events

private void LoadCurrToolValue ()
{
   while (AS3.GetLED (25));
   Thread.Sleep (500);
   
   exec.Setcurrenttool (Convert.ToInt32 (exec.Readkey ("MyCNC", "CurrentTool", "0")));
}


the missing CurrentTool value in the Default.pro file raises an exception (System.FormatException), rather than get the default value.