I released the first (beta) version of keyboard macros.
bug report are welcomed.
please be careful, it's a beta version
It should be loaded as one of the first plugins.
(like the Encoding plugins)
Thanks to Dan, who explained me, how
to approach this plugin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your quick answer and the advice to run
drpython 3.7.7 from 3.3.4. It's an good idea for everyone
having problems after upgrading drpython.
When doing this I get:
Traceback (most recent call last):
File "C:\drpy\drpython-3.7.7\drpython.py", line 2682, in
OnOpenRecentFile
self.OpenFile(filename, False)
File "C:/Dokumente und Einstellungen/Computer-
Verwalter/drpython/plugins\KeyBoardMacros.py", line 253,
in OpenMacroFile
if utf8Detect(oof):
NameError: global name 'utf8Detect' is not defined
I have to admit, that I installed both KeyBoardMacro and
3.7.7. So not 3.7.7 is the problem, but KeyBoardMacro.
Deinstalling KeyBoardMacro helped to fix my problem.
**********
Seems there is a small bug in KeyBoardMacros (unless this is an older version, in which case please disregard).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that can be bothersome, but depending on how deeply a plugin uses the internal code of drpython, it seems unavoidable.
What I should probably do is make an abstraction layer, so that plugin designers can run drpython functions entirely through a standard api, which does not change.
I have a few functions like that, but nothing for encoding.
However the name of the encoding file, and the functions therein, are highly unlikely to change again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>However the name of the encoding file, and the >functions therein, are highly unlikely to change again.
I agree,
anyway not so tragical.
The problem I think, is:
Suppose one have two plugins, who wants to overwrite the same functions (here OnNew and OnOpen). Now, only one plugin can use this method
of reassigning OnNew - OpenFile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I released the first (beta) version of keyboard macros.
bug report are welcomed.
please be careful, it's a beta version
It should be loaded as one of the first plugins.
(like the Encoding plugins)
Thanks to Dan, who explained me, how
to approach this plugin.
Date: 2004-12-19 16:20
Sender: ek13
Logged In: YES
user_id=1181136
Thanks for your quick answer and the advice to run
drpython 3.7.7 from 3.3.4. It's an good idea for everyone
having problems after upgrading drpython.
When doing this I get:
Traceback (most recent call last):
File "C:\drpy\drpython-3.7.7\drpython.py", line 2682, in
OnOpenRecentFile
self.OpenFile(filename, False)
File "C:/Dokumente und Einstellungen/Computer-
Verwalter/drpython/plugins\KeyBoardMacros.py", line 253,
in OpenMacroFile
if utf8Detect(oof):
NameError: global name 'utf8Detect' is not defined
I have to admit, that I installed both KeyBoardMacro and
3.7.7. So not 3.7.7 is the problem, but KeyBoardMacro.
Deinstalling KeyBoardMacro helped to fix my problem.
**********
Seems there is a small bug in KeyBoardMacros (unless this is an older version, in which case please disregard).
Hello,
oops, it seems, I have to update Keyboard macros
according to the last changes in init, Open File
and Onnew.
The difficulty is, every new DrPython version, I have
to take care, if something in the three section mentioned above, has changed.
Obviously:
from drUTF8 import utf8Detect, SetEncodedText, GetEncodedText
was missing.
I will upload Keyboard Macros 0.0.6 in a moment.
Franz
Yes, that can be bothersome, but depending on how deeply a plugin uses the internal code of drpython, it seems unavoidable.
What I should probably do is make an abstraction layer, so that plugin designers can run drpython functions entirely through a standard api, which does not change.
I have a few functions like that, but nothing for encoding.
However the name of the encoding file, and the functions therein, are highly unlikely to change again.
>However the name of the encoding file, and the >functions therein, are highly unlikely to change again.
I agree,
anyway not so tragical.
The problem I think, is:
Suppose one have two plugins, who wants to overwrite the same functions (here OnNew and OnOpen). Now, only one plugin can use this method
of reassigning OnNew - OpenFile.