New system plugin "Write result to file"

[Pako]

I made new system plugin "Write result to file".

Using:
Handover information the other program. For example for co-operation with application Samurize.


Testing:
a)Copy file WriteResultToFile.py to folder (for example) "C:\Program Files\EventGhost\plugins\System\"
b)Edit file __init__.py in folder (for example) "C:\Program Files\EventGhost\plugins\System\"
1)Find line "from Execute import Execute"
2)Before or behind this line insert new line with text "from WriteResultToFile import WriteResultToFile" (without quotes).
3)Find line " self.AddAction(ResetIdleTimer)"
4)Behind this line insert new line with text " self.AddAction(WriteResultToFile)" (without quotes).
Attention ! Must to be the same indent !
c)Copy file page_white_edit.png to folder (for example) "C:\Program Files\EventGhost\plugins\System\icons\"
d)Restart EG

Pray for corrections mine bad English.

Pako

[Pako]

I have new version of my plugin.
He has enhancement about option codepage.
Perhaps needs more improve, because for some options discovers UnicodeEncodeError.
Has it but sense solve ?

For data transfer to Samurize I advise use RAMdisk. Work it very nice.

Pako

[Bitmonster]

Well, I looked at it and I'm not sure if we should add it to the System actions. I think most people who knew how to use the eg.result variable and like to write some data to a file, will in most cases have no problem to write a simple script like:

Code: Select all

outfile = open("C:\\myfile.txt", "w")
outfile.write(str(eg.result) + "\n")
outfile.close()

or something like that.

And for most cases I can imagine, it is not enough to only write eg.result. It will very seldom be enough or the user would have to construct his eg.result with some additional actions. And then we are back in the domain of PythonScripts, that are much more versatile.

[Pako]

Well, I receive.
I'm think of less efficient user, which could make for instance this (see picture)
for example for logging.

Pako

[Pako]

I'm remake "Write result to file" plugin.
Now he have name "Write text to file". He is more versatile and he isn't system plugin, but "other" plugin.
Now he can write down not only {eg.result}, but also a variable - for instance "{eg.globals.RStitle}".
Plugin nowadays can serve also like a logger (added option "Log Times").
I think, that in these form would this plugin already may be incorporation to beta version.
Or still appear to be useless ?

Pako

[Bitmonster]

Looks much more practical. I will take a deeper look once 0.3.6 is officially released.

[Pako]

I made a new, greatly expanded version of the plugin "WriteTextToFile".
I used here the slightly modified function "ParseString" by Bitmonster.
New options:
Independent choice of input and output coding as well as "error handling."
New is choice of coding using the ComboBox. List of coding is stored in a separate file codecsList.py and everyone can adjust according to your needs.
In any coding can pick the "String write in the HexDump form". It is a very useful when debugging.
Pako

[Bitmonster]

Very nice. But the dialog gets to tall. Maybe the options for the encoding errors can be combined, since it will seldom make a difference if the error comes from the encoding or decoding.

[Pako]

... dialog gets to tall. Maybe the options for the encoding errors can be combined, since it will seldom make a difference if the error comes from the encoding or decoding.

Now it looks like maybe a little better.

Can someone please try it?
Pako

[Pako]

You can approve committal of this plugin to SVN ?

Thanks, Pako

[Bitmonster]

I think we can slim the dialog even more, by using only a wx.Choice for the encoding and adding "utf-8" and "current system codepage" (and maybe "hex dump" also) to the beginning of the list. Since there is only a fixed number of encodings available in Python, it doesn't make much sense to use a wx.ComboBox. The whole list of encodings you can see, if you open lib/python25.zip and list the "encodings" directory (except aliases.pyc and __init__.pyc). I guess, I can write a little helper function for this, like eg.GetAvailableEncodings() that will work with a normal Python installation and the py2exe setup. But for the start your list file is enough.

[Pako]

I think we can slim the dialog even more, by using only a wx.Choice for the encoding and adding "utf-8" and "current system codepage" (and maybe "hex dump" also) to the beginning of the list.

Well, this is not a problem to do. But HexDump choice I leave as is, because the conversion to hexadecimal view pass till after the encoding.

Since there is only a fixed number of encodings available in Python, it doesn't make much sense to use a wx.ComboBox.

Of course, I know that the user can not write any name coding. I had two reasons why I used wxComboBox and not wxChoice:
1) wxComboBox have the method SetValue and I am therefore able to write with the program into the box, for example, "System code page".
2) The user may prefer the keyboard and directly enter the name of the coding to box.

Because now everything will be on the list, paragraph 1) not relevant anymore. There is therefore no need (only for the paragraph 2) use the ComboBox.
Pako

[Bitmonster]

A wx.Choice can also be used with the keyboard. It will advance in the list as you type the keys. And it has the great benefit, that the user can't input an invalid encoding.

[Pako]

Here is the result. Finally, I not only rework layout, but have also been made small changes in function.
Instead of "Without decoding" is now in the list "unicode internal."
Pako

[Bitmonster]

Yes, the layout looks very good.

But after thinking about it, I'm not sure, if an input data encoding is really needed. Actually everything that comes from an action or piece of (right) code inside EG should already be unicode. Even if you type some Cyrillic text into a wx.TextCtrl, the result will already be an unicode string. So there is actually only a question how the output file should be encoded.