EventGhost

Hi

I'm rather new to Python / EG programming (but not to programming overall), so please forgive me if I should be wrong on the following. I think I've found a bug in the EG framework.

The documentation (writing_plugins.rst) states:
3. If the user presses the OK button the Configure() method has to return the
new parameters and if the plugin is enabled already, the plugins
:meth:`~eg.PluginBase.__stop__` method will be called and
immediately after that the :meth:`~eg.PluginBase.__start__`
method with the new parameters.

As I found, this works OK for simple configuration values. But it seems not to work if (just) a list was modified in the config dialog.
If Configure() just modifies a list, __stop__ / __start__ are never called after closing the dialog. However, the config data is stored correctly.

I'll attach a simple plugin demonstrating the issue. How to reproduce:
- add the plugin to some EG config
- confirm the initial config dialog of the plugin
- open the config dialog again
- select a value from the dropdown list and add it to the table
- click OK
=> __stop__ / __start__ is not called!
- modify the value field and click OK
=> __stop__ / __start__ is called

Am I doing something wrong or is it - as I claim - a bug in the framework?

Can someone confirm or deny?

phlox wrote:A) Am I doing something wrong or is it
B) - as I claim - a bug in the framework?

Dear Colleague!
I can assure you that case A) is correct .

Pako

thanks for the quick reply!

what's going wrong if the deep copy is omitted?

This simple.
Wrong is that in that case you have only a single instance of itemList.
And then is still true that itemList = itemList and EG does not detect any change.
Is that clear?

Pako

ah ok, all clear, thx.

I'm currently extending an (unreleased) plugin - I was not the only one not knowing that

one more question.
If data structures passed to Configure() aren't deep copied, the EG framework doesn't detect when they were changed. If one knows that internal detail of the framework, then it's simple, as you said
BUT: Why does the framework then write back the data to the XML config, even if it didn't detect a change (since structures were not deep copied)? That's an asymmetry, isn't it? Data is anyway written back to XML config, pretending the programmer that everything is all right, but __stop__ / __start__ isn't called since EG believes at the same time that data didn't change. I - and pretty sure others as well - wouldn't have been walking into that trap, if that were be symmetrical... So I'd suggest: EG should store config data to XML only if it (really) detects a change.
(sorry for my English, it's not my mother language, as might guess )

phlox wrote:If one knows that internal detail of the framework, then it's simple, as you said

You might have mistaken impression that I know these details. But here it was only by accident. I am had encountered the same problem (when I wrote Snarl plugin). So I was forced to look for, why it does not work ...

phlox wrote:BUT: Why does the framework then write back the data to the XML config, even if it didn't detect a change (since structures were not deep copied)? That's an asymmetry, isn't it? Data is anyway written back to XML config, pretending the programmer that everything is all right, but __stop__ / __start__ isn't called since EG believes at the same time that data didn't change. I - and pretty sure others as well - wouldn't have been walking into that trap, if that were be symmetrical... So I'd suggest: EG should store config data to XML only if it (really) detects a change.

Yes I agree, it's not quite right. But I am not the author. I'll try to find out how difficult it would be to fix. If I find that it is a small intervention then I'll do it.

phlox wrote:(sorry for my English, it's not my mother language, as might guess )

It is unnecessary to apologize. I do not speak English at all. I can not write so long a sentence like this, without a translator. Perhaps because English is not your native language, I understand your posts very well.

Pako

Pako wrote:Yes I agree, it's not quite right. But I am not the author. I'll try to find out how difficult it would be to fix. If I find that it is a small intervention then I'll do it.

wow, that would be great! I know, the original author unfortunately decided to leave the project. The more I'm really happy to see that someone like you (and others) drive the project forward again - I really believe in EG, it's a genious concept and a great implementation, just the plugins I'm using (iMON, DVBViewer, StandbyControl) lack a certain stability sometimes. That's why I decided to try to improve one of these plugins as far as I'm able to (and I'm learning )

So it seems that I've found it.
Finally, you probably were right - it's actually a bug.
This is due to incorrect behavior of python.
You can check it as follows:
In EventGhost open the shell (Help - Python Shell) and there you can try the following two examples:Bimonster probably did not anticipate that the list can also be an argument.
Unfortunately, just assign oldArgs = newArgs = ActionThreadFunc(item.GetArguments)() is causing our problem.
So I tried this:and it seems that the bug is fixed !
Can you please test it (corrected file Configure.py is attached)?
After the treatment is no longer necessary to use deepcopy inside the plugin.

Pako

yes, that seems to work. Many thanks!!