pythoncard-devel Mailing List for PythonCard (Page 9)

Alex Tweedly wrote on 05/18/2005 09:13:15 AM:
> Hmmm - baffling. Could you put this script in your resourceEditor 
> directory, and try it (with each version).
> #!/usr/bin/python
> 
> import sys, os
> from modules.propertyEditor import PropertyEditor
> 
> filename = sys.modules[PropertyEditor.__module__].__file__
> print filename
> 
> print os.getcwd(), os.listdir(".")
Ok, I created a script called alexTest.py and put it in 
/OMS/dev/pythonPackages/PythonCard/tools/resourceEditor.
While in that directory, I typed: python alexTest.py (this runs Python 
2.3.5)
Here is the output:
--------------------
/OMS/dev/pythonPackages/PythonCard/tools/resourceEditor/modules/propertyEditor.py
/OMS/dev/pythonPackages/PythonCard/tools/resourceEditor ['.cvsignore', 
'alexTest.py', 'CVS', 'images', 'modules', 'readme.txt', 
'resourceEditor.py', 'resourceEditor.rsrc.py', 'templates']
--------------------
Then I typed: python2.4 alexTest.py. 
It seemed to hang for about a minute, without generating any output. I 
typed control-C,
and got the following traceback:
----------------
^CTraceback (most recent call last):
 File "alexTest.py", line 4, in ?
 from modules.propertyEditor import PropertyEditor
 File 
"/OMS/dev/pythonPackages/PythonCard/tools/resourceEditor/modules/propertyEditor.py", 
line 8, in ?
 from PythonCard import dialog, font, model, registry, util
 File "/OMS/dev/pythonPackages/PythonCard/model.py", line 47, in ?
 import debug
 File "/OMS/dev/pythonPackages/PythonCard/debug.py", line 20, in ?
 from wx import py as PyCrust
 File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/py/__init__.py", 
line 7, in ?
 import buffer
 File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/py/buffer.py", 
line 7, in ?
 from interpreter import Interpreter
 File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/py/interpreter.py", 
line 10, in ?
 import dispatcher
 File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/py/dispatcher.py", 
line 9, in ?
 import weakref
 File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/weakref.py", 
line 14, in ?
 from _weakref import (
KeyboardInterrupt
---------------

> The same thing happens with the normal Resource Editor. I am using a
> PythonCard from CVS which is about a week old. 
> Hmmm - baffling. Could you put this script in your resourceEditor 
> directory, and try it (with each version).
Ok, I'll do that later today.
> 
> I'll try and get a clean Windows machine and download Python 2.4 
> onto it, but it may take me a couple of days to find a suitable 
> machine; and if it turns out to be Mac-specific then I have no way 
> to test it in the near future.
I have a Windows PC at home running Python 2.4, and I may be able to carve
out some time with it in the next few days to see if I can duplicate
the problem.
Because my project is getting close to a very tough deadline,
I think I'll stick to Python 2.3.x for now. I'm afraid of other
unexpected problems related to Python 2.4 cropping up, since
it's unclear whether PythonCard has really been tested
thoroughly against Python 2.4.

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.11 - Release Date: 16/05/2005

Sorry for the delayed response on this. It looks like the problem only 
happens under Python 2.4.1, not under 2.3.5. I'm running this on Mac OS 
10.4.0. 
Alex Tweedly <al...@tw...> wrote on 05/13/2005 07:21:50 PM:
> This comes from the line (around model.py line 212):
> filename = sys.modules[frameClass.__module__].__file__
> # chop the .pyc or .pyo from the end
> base, ext = os.path.splitext(filename)
> filename = internationalResourceName(base)
> I wonder if this is a difference with Python 2.4 (I'm still on 2.3.4)
> 
> I added a debug line, to get:
> filename = sys.modules[frameClass.__module__].__file__
> # chop the .pyc or .pyo from the end
> print filename, parent, frameClass
> base, ext = os.path.splitext(filename)
> filename = internationalResourceName(base)
> 
> to confirm that, for me, it did properly get the path name including
> "/modules/propertyEditor".
> 
> Could you add that same line, and then try it again - and also try 
> the normal resourceEditor to see what they each say ?
Under Python 2.4.1 and wxPython 2.6:
/OMS/dev/misc/newresourceEditorv0.3a/propertyEditor.py 
<__main__.ResourceEditor; proxy of C++ wxFrame instance at 
_0190c800_p_wxFrame> <class 'modules.propertyEditor.PropertyEditor'>
Under Python 2.3.5 and wxPython 2.5.3.1:
/OMS/dev/misc/newresourceEditorv0.3a/modules/propertyEditor.py 
<__main__.ResourceEditor; proxy of C++ wxFrame instance at 
_003e8500_p_wxFrame> <class 'modules.propertyEditor.PropertyEditor'>
The same thing happens with the normal Resource Editor. I am using a 
PythonCard from CVS which is about a week old.

Andy Todd wrote:
> How's it going? If you haven't mastered the technology I ran across 
> this howto today;
>
> http://haacked.com/archive/2005/05/12/3178.aspx
>
> Courtesy of Phil Rignalda 
> http://philringnalda.com/blog/2005/05/less_scary_docs_are_good_docs.php
Going OK now thanks Andy. I had a typo in my notes - and copy/pasted it 
into my current system; as soon as I fixed that, I was fine. Would have 
reported this on the list - but thought that doing the commits the other 
day would be report enough :-)
One more bug fix to go into the mainline, then I'm ready to do the 
branching ....
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 12/05/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 12/05/2005

pyt...@li... wrote on 05/13/2005 05:39:06 
PM:
> could you apply the diff I enclosed in the earlier email to help 
> debug the problem.
Ok, I applied the diff (manually -- I'm not sure how to automatically 
merge
a diff string like that into a file). 
Now, I've moved on to a different error message, which basically still 
confirms
that the resource file was not found. I guess it's the 
propertyEditor.rsrc.py that 
it can't find. I have it in /OMS/dev/misc/newresourceEditorv0.3a/modules, 
and
am running the resourceEditor from within 
/OMS/dev/misc/newresourceEditorv0.3a
so I wonder why it can't find it?
Here is the new traceback.
oms-ballen:/OMS/dev/misc/newresourceEditorv0.3a ballen$ pythonw2.4 
resourceEditor.py
no resource file for /OMS/dev/misc/newresourceEditorv0.3a/propertyEditor
Traceback (most recent call last):
 File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", 
line 11904, in <lambda>
 lambda event: event.callable(*event.args, **event.kw) )
 File "resourceEditor.py", line 168, in on_initialize
 self.propertyEditorWindow = model.childWindow(self, PropertyEditor)
 File "/OMS/dev/pythonPackages/PythonCard/model.py", line 212, in 
childWindow
 rsrc = resource.ResourceFile(filename).getResource()
 File "/OMS/dev/pythonPackages/PythonCard/resource.py", line 45, in 
__init__
 self.dictionary = util.readAndEvalFile(rsrcFileName)
 File "/OMS/dev/pythonPackages/PythonCard/util.py", line 37, in 
readAndEvalFile
 f = open(filename)
TypeError: coercing to Unicode: need string or buffer, NoneType found

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 12/05/2005

Alex Tweedly wrote on 05/12/2005 07:28:24 PM:
> 
> Apologies if this is a dumb question, but I'm not sure how best to 
> handle this error condition.
> 
> I discovered that if you start a Pythoncard script when the main 
> script's resource file is missing, you get an error condition; the code 
> in model.py/internationalResourceName() assumes that there will be at 
> least one matching resource file.When there isn't, it tried to use an 
> un-initialized variable .... clearly not the right thing to do.
> 
> It's easy enough to detect the situation - but what should we then do ?
I'm seeing this error when I launch the new Resource Editor .3, even 
though
it clearly does have a Resource File. 
Here is the traceback:
Traceback (most recent call last):
 File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", 
line 11904, in <lambda>
 lambda event: event.callable(*event.args, **event.kw) )
 File "resourceEditor.py", line 168, in on_initialize
 self.propertyEditorWindow = model.childWindow(self, PropertyEditor)
 File "/OMS/dev/pythonPackages/PythonCard/model.py", line 208, in 
childWindow
 filename = internationalResourceName(base)
 File "/OMS/dev/pythonPackages/PythonCard/model.py", line 178, in 
internationalResourceName
 return filename
UnboundLocalError: local variable 'filename' referenced before assignment

Apologies if this is a dumb question, but I'm not sure how best to 
handle this error condition.
I discovered that if you start a Pythoncard script when the main 
script's resource file is missing, you get an error condition; the code 
in model.py/internationalResourceName() assumes that there will be at 
least one matching resource file.When there isn't, it tried to use an 
un-initialized variable .... clearly not the right thing to do.
It's easy enough to detect the situation - but what should we then do ?
See below for the diff of my current version showing the problem .....
> C:\python\PythonCard>cvs 
> -d:ext:ale...@cv...:/cvsroot/pythoncard diff
> cvs -d:ext:ale...@cv...:/cvsroot/pythoncard diff
> ? tools/standaloneBuilder/customDialogs.pyc
> ? tools/standaloneBuilder/outputWindow.pyc
> ? tools/standaloneBuilder/pmbuild.bat
> ? tools/standaloneBuilder/pmbuild.out
> ? tools/standaloneBuilder/standaloneBuilder.ini
> cvs diff: Diffing .
> Index: model.py
> ===================================================================
> RCS file: /cvsroot/pythoncard/PythonCard/model.py,v
> retrieving revision 1.191
> diff -c -r1.191 model.py
> *** model.py 30 Mar 2005 18:07:39 -0000 1.191
> --- model.py 13 May 2005 00:21:35 -0000
> ***************
> *** 171,180 ****
> --- 171,183 ----
> filenames.insert(0, base + '.' + platform + '.' + 
> language + '_' + country + postfix)
> 
> log.debug(filenames)
> + filename = None
> for f in filenames:
> if os.path.exists(f):
> filename = f
> break
> + if not filename:
> + print "no resource file for", base
> return filename
> 
> 
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005

Alex Tweedly wrote:
> 
> Sigh. I hate CVS.
> 
> Problem: when I try to do a commit, I get the error
> cvs [server aborted]: "commit" requires write access to the repository
> cvs commit: saving log message in C:\DOCUME~1\Eleane\LOCALS~1\Temp\cvs5
> 
> Background:
> I haven't used cvs much at all. Last July or August or so Kevin walked 
> me through the process of getting set up, and I was able to commit stuff 
> OK. I haven't had anything to commit since maybe September or October - 
> so I've had plenty time to forget things.
> 
> In the meantime, my laptop has died, and I've brought everything back 
> from backups on to a new machine - so I've had plenty of opportunity to 
> forget things.
> 
> Foreground:
> I've reloaded Putty/Pageant, and restored my ppk file.
> I've installed cvs.
> I've added my sourceforge key to pageant
> I've brought up Putty connection over ssh to cvs.sorceforge.net - and 
> get the message
> "authenticating to cvs.sourceforge.net using public key" etc. just as I 
> remembered.
> 
> I then do a
> cvs -d:pserver:ale...@cv...:/cvsroot/pythoncard login
> and when prompted give my password - and when I type it correctly, get 
> no error. (I mis-typed it just to check - and that does give an error).
> 
> I can do cvs checkout, cvs update, cvs diff, etc. but when I do a cvs 
> commit, after entering the log file info, I get the error as above, i.e.
> cvs [server aborted]: "commit" requires write access to the repository
> cvs commit: saving log message in C:\DOCUME~1\Eleane\LOCALS~1\Temp\cvs5
> 
> Question:
> anything obvious I've forgotten or done wrong ?
> any suggestions ?
> 
> Thanks
> -- Alex.
> 
I don't use this combination of tools so can't help directly. But it 
sounds to me like you are identifying yourself to SourceForge correctly. 
A quick Google;
 
http://www.google.com/search?hl=en&q=cvs+%5Bserver+aborted%5D%3A+%22commit%22+requires+write+access+to+the+repository&btnG=Google+Search
Gives these examples;
http://lists.gnu.org/archive/html/info-cvs/2001-08/msg01282.html
http://lists.parisc-linux.org/pipermail/parisc-linux/1999-September/011406.html
Can I suggest you open a support ticket at SourceForge as they are a lot 
better at sorting these things out than I am ;-)
Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Sigh. I hate CVS.
Problem: when I try to do a commit, I get the error
cvs [server aborted]: "commit" requires write access to the repository
cvs commit: saving log message in C:\DOCUME~1\Eleane\LOCALS~1\Temp\cvs5
Background:
I haven't used cvs much at all. Last July or August or so Kevin walked 
me through the process of getting set up, and I was able to commit stuff 
OK. I haven't had anything to commit since maybe September or October - 
so I've had plenty time to forget things.
In the meantime, my laptop has died, and I've brought everything back 
from backups on to a new machine - so I've had plenty of opportunity to 
forget things.
Foreground:
I've reloaded Putty/Pageant, and restored my ppk file.
I've installed cvs.
I've added my sourceforge key to pageant
I've brought up Putty connection over ssh to cvs.sorceforge.net - and 
get the message
 "authenticating to cvs.sourceforge.net using public key" etc. just as 
I remembered.
I then do a
cvs -d:pserver:ale...@cv...:/cvsroot/pythoncard login
and when prompted give my password - and when I type it correctly, get 
no error. (I mis-typed it just to check - and that does give an error).
I can do cvs checkout, cvs update, cvs diff, etc. but when I do a cvs 
commit, after entering the log file info, I get the error as above, i.e.
cvs [server aborted]: "commit" requires write access to the repository
cvs commit: saving log message in C:\DOCUME~1\Eleane\LOCALS~1\Temp\cvs5
Question:
anything obvious I've forgotten or done wrong ?
any suggestions ?
Thanks
-- Alex.
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005

Alex Tweedly wrote:
> 
> Up till now, everything's been fine and easy on the new resource editor 
> - all self-contained within the resource editor itself.
> 
> But for the "new naming rules", I'd really like those rules to be 
> maintained and used over multiple incantations of the resource editor - 
> which means I need to store the info about which names/labels/texts are 
> user-specified and which are derived. The obvious place to put this is 
> in a new attribute (actually, 2 new attributes) of a component - which 
> means changing Pythoncard/widget.py
> 
> I think adding new attributes is "safe" - can't see how it would 
> adversely impact anything - but it means changes outside the editor 
> itself. Additional attributes are simply ignored of the resource file 
> is read in by resource.ResourceFile so the resource files are still good 
> to use with earlier version of Pythoncard or earlier versions of the 
> resourceEditor.
> 
> Would anyone object to my adding a new attribute or two, for use only 
> (currently, at least) within the resource editor ?
> 
> How about another attribute, for use with geometry manager(s) / sizers, 
> etc. ?
> For this, I'd propose a generically named attribute per component - just 
> one string, packed with info as needed - and then it can be used by any 
> geometry schemes that want to use it.
> 
> 
Sounds like it's time to check your changes into CVS (am I beginning to 
repeat myself?). I have no objection to adding an attribute for your new 
naming rules. You explained quite well how this will work in your other 
message(s) and persisting it across sessions looks like a good idea to me.
As I may have mentioned before probably the best way to do this is in a 
new CVS branch. When your changes are in, tested and working like a 
charm we can then merge them back into the main body of the code and 
think about a 0.9 release - but I'm getting ahead of myself ;-)
As for another geometry attribute - I'd like to see a little more 
thought and/or use cases before we add anything. And if we do get that 
far having a single attribute with multiple values/meanings is 
definitely a no-no as far as I'm concerned.
Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Up till now, everything's been fine and easy on the new resource editor 
- all self-contained within the resource editor itself.
But for the "new naming rules", I'd really like those rules to be 
maintained and used over multiple incantations of the resource editor - 
which means I need to store the info about which names/labels/texts are 
user-specified and which are derived. The obvious place to put this is 
in a new attribute (actually, 2 new attributes) of a component - which 
means changing Pythoncard/widget.py
I think adding new attributes is "safe" - can't see how it would 
adversely impact anything - but it means changes outside the editor 
itself. Additional attributes are simply ignored of the resource file 
is read in by resource.ResourceFile so the resource files are still good 
to use with earlier version of Pythoncard or earlier versions of the 
resourceEditor.
Would anyone object to my adding a new attribute or two, for use only 
(currently, at least) within the resource editor ?
How about another attribute, for use with geometry manager(s) / sizers, 
etc. ?
For this, I'd propose a generically named attribute per component - just 
one string, packed with info as needed - and then it can be used by any 
geometry schemes that want to use it.
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 04/05/2005

Just checked in another minor amendment - I've added a 'Run' button to
the main window and fixed a bug which I found in the code which
generates a new project.
The code appears to be pretty stable now, this is the first change I've
had to make in almost 3 weeks of constantly using the program for my own
development work.
I'll leave off posting anything to the main users list about this until
Alex has finished with testing his enhanced resource editor. I do need
some help with this now from someone who can get it working with py2exe
as well as McMillan Installer - any volunteers?
The documentation also needs a few tweaks. As I've added new UI
elements, the screen shots no longer reflect the appearance of the
current version. There are also some speeling mistooks in the text which
need correcting. I'll tend to these tasks shortly and check in the
revised documentation at the weekend.
-- 
Regards
Phil Edwards
Brighton, UK

Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/2005

Andy Todd wrote:
> Alex Tweedly wrote:
>
>> I decided to tackle this - and was amazed to find how easy it was (or 
>> at least, seems to have been). In about 1-1/2 days I've go this up 
>> and running (as far as I can tell with the limited testing I've done 
>> so far). I don't know of any NEW bugs - but I've run into a few that 
>> all seem to be there in the released version (0.8.1 - not cvslatest).
>
> If it's working for you I think you should check it into CVS. If you 
> inadvertently introduce any serious bugs we can always back out your 
> changes, that's the joy of version control.
Thanks Andy, but it is, IMHO, too big a behaviour change to check in 
without getting some agreement.
I'm actually not (in this case) worried so much about a serious bug, but 
more about a serious surprise for users.
I think this style is much better, though quite different - but I 
decided to give myself this week (i.e. until end of tonight, Friday) to 
work on it, then post to the users list to ask people to have a look and 
see what they think.
Incidentally, I did get carried away .... so as well as the simple 
"panel display" change, it also has buttons for changing layers, moving 
the component (alternative to arrow-keys), and multiple component 
selection and manipulation as well. Don't yet have all the obvious 
manipulations; I've got move, align, distribute and equalize - haven't 
yet got delete, copy or re-layer - for multiple components.
(I do have separate diffs so can commit only the panel changes if I need 
to).
Anyway - look for a posting to the users list tonight with a version to 
take a look at.
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/2005

Alex Tweedly wrote:
> On Pythoncard-users, Alex Tweedly wrote:
> 
>>
>> C. Resource Editor
>>
>> (these are in descending order of importance to me, or increasing 
>> difficulty of implementation)
>>
>> 1. property editor window.
>> I find the current property window pretty clunky. Instead of 
>> displaying (and allowing editing of) one property at a time, with a 
>> list to select which property, I'd rather see a "display panel" 
>> approach where all the properties of the current component were shown 
>> (and all available for direct editing). If this takes up too much 
>> screen real-estate, we could drop back to showing one of a number of 
>> subsets (basic, appearance, etc.) - but given that there relatively 
>> few properties, I think this won't be a problem.
> 
> 
> I decided to tackle this - and was amazed to find how easy it was (or at 
> least, seems to have been). In about 1-1/2 days I've go this up and 
> running (as far as I can tell with the limited testing I've done so 
> far). I don't know of any NEW bugs - but I've run into a few that all 
> seem to be there in the released version (0.8.1 - not cvslatest).
> 
If it's working for you I think you should check it into CVS. If you 
inadvertently introduce any serious bugs we can always back out your 
changes, that's the joy of version control.
Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005

Alex Tweedly wrote on 04/26/2005 07:39:39 PM:
> I was able to get the resizing to misbehave readily, but have had 
> less success finding failures in the move operation (with mouse - 
> not talking about arrow keys here).
> Do you have any other "recipes" for getting the move component 
> failures to happen ? 
> Do you see them on all platforms ?
Yes, I do see moving problems here and there with some widgets.
Here is a recipe for the ComboBox bug:
ComboBox on Mac OS 10.3.8, wxPython 2.5.5.1, PythonCard from CVS:
 Open Resource Editor. Create a new ComboBox. Try to move it
and you will probably have difficulty. The only way to move
it is to grab the edge. Grabbing the middle doesn't work,
nor does grabbing the popup menu handle on the right side.
ComboBox on Windows XP, wxPython 2.5.3 ansi, PythonCard .81:
 On Windows the behavior is slightly different for
ComboBox. You can grab the right popup menu handle
to move the ComboBox (at least you can most of the time),
but try grabbing the middle of the ComboBox and you may
see some strange behavior. If it doesn't happen right away,
keep trying.
Alex Tweedly wrote on 04/26/2005 07:39:39 PM:
> I can make it misbehave - by double clicking in a component and then
> clicking outside it - the component is selected for moving, and 
> further unrelated mouse events seem to be ignored (solved by giving 
> focus to another app, then back to this one!)
I've also seen another type of resizing problem, only affecting
buttons on the Mac. Sometimes a button will not allow itself to be
resized vertically, only horizontally. Often, I'll see a button
that was created under Windows look very strange on a Mac,
because the visual outlines of the button don't match the outlines
of the widget (the little square handles are not in the right places).
Usually the only way to resize is to edit the resource file manually,
though on some occasions I can resize the button in the Resource
Editor to fix the problem.

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005

Currently we say that a component name "must start with a letter and 
contain only letters and numbers"
As far as I know this is only checked in the resource editor, and was 
only done to ensure that the component events could be identified 
readily (e.g on_ followed by name followed by _eventtype )
Neither of those matter if you have an app which creates its components 
dynamically, and doesn't depend on name-based event binding (i.e.it 
doesn't use events at all, or uses commands, or catch-all events, or 
wxPython events).
So,
1. is there anything else I've forgotten about that would break ?
2. do you think anyone is using this already ?
3. could (should) we reserve some such names ?
Specifically, I'm thinking about generalizing the sizing handles in the 
resource editor. Currently it knows there is exactly one set of sizing 
handles, and reserves component slots 0:7 for them (and simply reserves 
the names of them). If we are to select multiple components, it's 
probably easier to use a name convention for sizing handles than it is 
to keep track of the number of selected components and manipulate the 
component order accordingly. Therefore, I'd like to have a large number 
of "reserved" names which couldn't clash with users' component names.
I was considering reserving all component names beginning with "_" for 
system use - and specifically "_sh_" for the sizing handles. What do 
you think ?
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005

I've been looking into the "flaky behaviour while resizing" that various 
people have mentioned (I have to admit I hadn't noticed it myself, but 
was able to make it happen fairly easily once I started trying).
I'm pretty sure I know what the problem is - but not yet 100% sure I 
have the *right* solution; so if anyone is familiar with this aspect of 
the code, and can confirm my thoughts, I'd be grateful. If someone who 
isn't familiar with it would be willing to offer an opinion - I'd still 
be grateful for that :-)
There is a chunk of code (see below) at the start of the doResize() 
function. Normally, you get here indirectly from on_mouseDrag(), because 
of a wxPython event captured because of
 wx.EVT_MOTION(self.panel, self.on_mouseDrag)
So, normally, the "try" clause fails - wxPython events have no member 
event.x, and the "except" clause is used. (i.e. ignore the comments 
about Windows vs Mac/Linux).
However, if you are extending the right side of say a Textfield 
outwards, and then move back to the left rapidly, you generate a 
mouseDrag event *within* the textfield - and hence a PythonCard event 
triggers on_mouseDrag(). This gets through the "try" clause - and, well, 
almost anything can happen - you start mixing client and screen coords.
I *think* the "try" clause is simply obsolete code, from some earlier 
incarnation when the Windows version used a different event capture 
mechanism, and the fix is to simply remove the "try ...... except" 
lines. This certainly *seems* to work in my testing - but I'm still wary 
of just doing that without some confirmation.
> def doResize(self, event, (n, w, s, e)):
> if not self.startName:
> return
>
> try:
> # Windows
> xOffset = event.x - self.offset[0]
> yOffset = event.y - self.offset[1]
> except:
> # Mac OS X and Linux/GTK
> #x, y = event.GetPosition()
> globalPosition = wx.GetMousePosition()
> x, y = 
> self.components[self.resizingHandleTarget].ScreenToClient(globalPosition)
> xOffset = x - self.offset[0]
> yOffset = y - self.offset[1]
>
> xStartOffset = self.startPosition[0] + e * xOffset
> yStartOffset = self.startPosition[1] + n * yOffset
-- Alex.
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005

On Pythoncard-users, Alex Tweedly wrote:
>
> C. Resource Editor
>
> (these are in descending order of importance to me, or increasing 
> difficulty of implementation)
>
> 1. property editor window.
> I find the current property window pretty clunky. Instead of 
> displaying (and allowing editing of) one property at a time, with a 
> list to select which property, I'd rather see a "display panel" 
> approach where all the properties of the current component were shown 
> (and all available for direct editing). If this takes up too much 
> screen real-estate, we could drop back to showing one of a number of 
> subsets (basic, appearance, etc.) - but given that there relatively 
> few properties, I think this won't be a problem.
I decided to tackle this - and was amazed to find how easy it was (or at 
least, seems to have been). In about 1-1/2 days I've go this up and 
running (as far as I can tell with the limited testing I've done so 
far). I don't know of any NEW bugs - but I've run into a few that all 
seem to be there in the released version (0.8.1 - not cvslatest).
Before I go and look into these, I thought I'd just check to see if 
anyone else has seen these, or looked at them at all, or have any 
ideas/suggestions, or ...
1. Menu selection using Alt- sequences (WinXP) are flaky. Shortcuts 
always appear to work, as does the mouse - but sometimes the Alt-key 
sequences don't - the "primary" letters show as underlined, but other 
letters don't trigger any action that I can see.
2. Moving components using arrow keys is flaky.
Usually it works, but after selecting some component types, the arrow 
keys stop working. Noticed this with Bitmap Canvases, and I *think* I've 
seen it with other components. Once they've stopped, it's hard to get 
them to work again but can be done most days.
3. Clicking on the "File..." button to specify a file name (for an Image 
or ImageButton) will fail unless the background has already been saved. 
(This seems to give a value of None to one of the path names, and hence 
cause an error in Pythoncard/util.relativepath).
Any ideas ? Or should I start debugging these ?
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 21/04/2005