Wish: a __delete__(self) method for plugins

Do you have questions about writing plugins or scripts in Python? Meet the coders here.
Post Reply
krambriw
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Wish: a __delete__(self) method for plugins

Post by krambriw » Sun Mar 09, 2008 3:03 pm

Hi,
I would like to do some additional stuff when I delete a plugin that I cannot put in the __close__(self) method.

Would it be possible to add a method like __delete__(self) ?

Best regards, Walter

User avatar
dexter98
Plugin Developer
Posts: 49
Joined: Sun Dec 30, 2007 2:45 am
Location: Netherlands
Contact:

Re: Wish: a __delete__(self) method for plugins

Post by dexter98 » Tue Mar 11, 2008 11:05 pm

Why couldn't you put this 'stuff' into the __close__ method?

edit:
def __init__(self): is an build-in function in Python. It's automatically called on object creation.
The destructor-equivalent in Python is def __del__(self):

User avatar
Bitmonster
Site Admin
Posts: 2239
Joined: Mon Feb 06, 2006 10:28 pm

Re: Wish: a __delete__(self) method for plugins

Post by Bitmonster » Wed Mar 12, 2008 12:01 am

Well, I guess he wants to delete some files his plugin has created when the user deletes the plugin from the configuration.

But I still not see why the Velleman plugin would need to write any file.

And it won't work for example if the user has two configuration in use for example. How do you want to find out which files belong to the current configuration?
Please post software-related questions in the forum - PMs will only be answered, if really private, thanks!

krambriw
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Re: Wish: a __delete__(self) method for plugins

Post by krambriw » Wed Mar 12, 2008 7:25 am

You are guessing right...I had in mind cleaning away some files when the user deletes the plug-in :oops:

You say they user has two configurations in use. Can you tell me more what you think of here?

In a computer you can have maximum 4 boards at the same time with addresses 0-3. I keep the file names related to board addresses, But are you thinking of having multiple eg xml's that the user is toggling between?

I would really be happy to avoid the files. I have tried to clean up the plug-in according to your advice, can you look at it and see if its possible to make the configuration settings persistent in another way?

The current version works in the following:
- the board, inputs, outputs and counters are separate classes
- the plugin starts the board
- the actual "board class" reads configuration for counters, analog values and digital input levels from files
- the configurations are now available to the thread that polls the inputs and counters and raises events if the criterias are fullfilled
- when the plugin is stopped, the configurations are saved to files to be used next startup

I assume the configuration you make for inputs, outputs and counters are "somewhere" but at startup I need to provide them to the "board class". Therefore I currently use files because I dont know how to reach the original settings in the other classes...

Please, help

Best regards, Walter

Post Reply