Menu
▾
▴
pythoncard-devel — PythonCard Developers List
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(21) |
May
(24) |
Jun
|
Jul
(16) |
Aug
(28) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(9) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(24) |
Jun
(5) |
Jul
(2) |
Aug
(3) |
Sep
(4) |
Oct
(8) |
Nov
(37) |
Dec
(25) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(1) |
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <bra...@om...> - 2005-05-18 20:55:20
|
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
--------------- |
|
From: <bra...@om...> - 2005-05-18 15:22:46
|
> 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. |
|
From: Alex T. <al...@tw...> - 2005-05-18 14:13:23
|
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 |
|
From: <bra...@om...> - 2005-05-18 01:29:16
|
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. |
|
From: Alex T. <al...@tw...> - 2005-05-16 19:46:38
|
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 |
|
From: Alex T. <al...@tw...> - 2005-05-14 00:22:02
|
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 |
|
From: <bra...@om...> - 2005-05-13 23:46:48
|
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
|
|
From: Alex T. <al...@tw...> - 2005-05-13 22:39:19
|
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 |
|
From: <bra...@om...> - 2005-05-13 21:55:22
|
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
|
|
From: Alex T. <al...@tw...> - 2005-05-13 00:30:16
|
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 |
|
From: Andy T. <an...@ha...> - 2005-05-10 21:13:50
|
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/ |
|
From: Alex T. <al...@tw...> - 2005-05-10 16:45:29
|
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 |
|
From: Andy T. <an...@ha...> - 2005-05-09 08:38:50
|
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/ |
|
From: Alex T. <al...@tw...> - 2005-05-05 18:12:17
|
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 |
|
From: Phil E. <ph...@li...> - 2005-05-05 13:11:31
|
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 |
|
From: Neateye <nit...@ao...> - 2005-05-02 18:17:57
|
Call out Gouranga be happy!!! Gouranga Gouranga Gouranga .... That which brings the highest happiness!! |
|
From: Alex T. <al...@tw...> - 2005-04-30 10:18:02
|
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 |
|
From: Alex T. <al...@tw...> - 2005-04-29 14:03:59
|
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 |
|
From: Andy T. <an...@ha...> - 2005-04-29 12:46:46
|
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/ |
|
From: Alex T. <al...@tw...> - 2005-04-27 18:58:08
|
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 |
|
From: <bra...@om...> - 2005-04-27 02:02:47
|
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.
|
|
From: Alex T. <al...@tw...> - 2005-04-27 00:39:41
|
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 |
|
From: Alex T. <al...@tw...> - 2005-04-27 00:30:31
|
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 |
|
From: Alex T. <al...@tw...> - 2005-04-26 21:51:00
|
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
|
|
From: Alex T. <al...@tw...> - 2005-04-26 01:10:10
|
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 |
37 messages has been excluded from this view by a project administrator.
