pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] Thinking about Filemaker replacement

[normanwinn <nor...@on...>]

Hi,

I make an apology first. After an initial burst of activity, I  haven't 
been doing much in actually using PythonCard. This doesn't mean my 
interest has not been fired. However, my initial interest was my quest 
to see if a Filemaker replacement might be possible.

What I have been doing is looking around in the open source community 
for the various components that might contribute to such an enterprise.

Database engine: 
I have messed around with Firebird and it seems OK. Then I noticed that 
sqlite - that I had been avoiding - is not too fussy about storage types 
and requires no pre-definition of data size. This would appear to offer 
a potential fit to the way Filemaker operates on data. The problem with 
sqlite - at least I think it is a problem - is that it is does not 
follow the client/server model. However, for the smallish companies that 
dominate the Filemaker client base, sqlite may service requests rapidly 
enough for this not to be a problem.

What may be being worked on is a front end queuing mechanism that will 
serve requests to sqlite. It appears that sqlite might evolve towards a 
client/server model.

Sqlite is moving to version 3. This gives a choice of specifying data 
types or not which makes it an even better match for how Filemaker 
represents data.

A reporting tool:
Kevin Altiss found the excellent discussion on Filemaker replacement on 
slashdot. One comment in this thread made me realise how important an 
area Filemaker's reporting is. That thread also led me to DataVision 
(http://datavision.sourceforge.net/) which I haven't tried but looks a 
very promising report tool that would be much more powerful and flexible 
than that of Filemaker.

Extracting/converting data from Filemaker:
pyFilemaker seems to extract as much as FM is willing to give. An 
interesting project in PythonCard would be to attempt to generate a 
default database front end from this information. This would only be 
bare bones compared with how the Filemaker front end would look, but 
often, having a place to start is enough to get one going.

Well, this is not an exhaustive list of what would need to be done but I 
thought it worth giving this report as the initial discussion seemed to 
generate interest.


I must add in conclusion that I am enjoying learning Python and have 
produced a tool I use every day in relation to Filemaker. It is called 
'xpdfBatch.py' (or xpdfBatch.exe) and produces this output when invoked 
from the command line with the '-h' option:

xpdBatch.py - extracts text from pdf files in current folder.
             Depends on pdftotext from Glyph & Cog, LLC:
                 http://www.foolabs.com/xpdf/

    Usage: with no arguments processes pdf files not already done
           If argument is:
           a pdf file: (must be quoted if containing spaces) process 
that file
           'all': (without the quotes) process all pdf files. Any '.txt' 
files
           existing will be overwritten.
           -h: show this help

I use it as Filemaker prints scripts only as pdf. 
Haven't tested it on the Mac yet but will.

I have been very impressed by the patience and helpfulness of this 
community,

Norman

Re: [Pythoncard-users] Calendar GUI to share?

[Kevin A. <al...@se...>]

On Oct 11, 2004, at 11:13 AM, Gregory Pi=F1ero wrote:

> Hi,
>
> I'm about to write a calendar GUI with python card.  It would be
> similar to what outlook has (but just the calendar part).  I just
> wanted to check if anyone on the list has made something similar in
> the past that would be easy to use/modify and wants to share?  Or does
> anyone know of any ready-made python/python card/wxpython calendar
> GUI's I could plug into my python app fairly easily?
>
> Otherwise I'll set off on making my own.  Let me know.
>
> Thanks,
>
> Greg
>
There is the Calendar component which wraps wx.calendar.CalendarCtrl.=20
wxPython also has another control wx.lib.calendar.Calendar. Regardless=20=

of how you plan to implement your Calendar, you should probably discuss=20=

it on wxPython-users as it is quite likely people on that list would be=20=

interested and able to help. There is also the calendar stuff being=20
done for Chandler.

http://www.osafoundation.org/

If you wanted to do a quick prototype using PythonCard, it would be=20
relatively easy to translate that into raw wxPython which would give it=20=

a broader audience. If you already have a list of requirements, you=20
should make that part of your initial email to wxPython-users. Feel=20
free to start a wiki page if you want to simplify contributions from=20
multiple people.

ka

[Pythoncard-users] Calendar GUI to share?

[<gre...@gm...>]

Hi,

I'm about to write a calendar GUI with python card.  It would be
similar to what outlook has (but just the calendar part).  I just
wanted to check if anyone on the list has made something similar in
the past that would be easy to use/modify and wants to share?  Or does
anyone know of any ready-made python/python card/wxpython calendar
GUI's I could plug into my python app fairly easily?

Otherwise I'll set off on making my own.  Let me know.

Thanks,

Greg

[Pythoncard-users] Calendar GUI to share?

[<gre...@gm...>]

Hi,

I'm about to write a calendar GUI with python card.  It would be
similar to what outlook has (but just the calendar part).  I just
wanted to check if anyone on the list has made something similar in
the past that would be easy to use/modify and wants to share?  Or does
anyone know of any ready-made python/python card/wxpython calendar
GUI's I could plug into my python app fairly easily?

Otherwise I'll set off on making my own.  Let me know.

Thanks,

Greg

[Pythoncard-users] if you want to help test release 0.8.1...

[Kevin A. <al...@se...>]

Unless people bring up some bugs that need immediate fixing, the code 
that is currently in cvs will probably get turned into release 0.8.1 
around the end of next week. It looks like wxPython 2.5.3.x won't get 
released for at least 2-3 weeks and I want to get 0.8.1 out before the 
PythonCard sprint in Bellevue (Seattle) on Oct. 23-34. Release 0.8.1 
will work with wxPython 2.5.2.8 or later.

The tabbed codeEditor that Alex is working on is a bit new to replace 
the existing codeEditor, so the old single window version will still be 
in 0.8.1, though we may include the tabbed version and initial 
resourceEditor integration experiments in another directory so more 
people can play with the code.

If you are working from cvs, I would appreciate reports of problems 
ASAP.

Thanks,

ka

[Pythoncard-users] fwd: WATSUP - Windows Application Test System Using Python

[Kevin A. <al...@se...>]

I would eventually like to have a way of doing more unit tests and 
automated testing of the GUI elements in PythonCard. For anyone 
interested in pursuing this, WATSUP might be a good project to 
contribute to or learn from.

http://www.tizmoi.net/watsup/intro.html

ka

[Pythoncard-users] PythonCard conference plans for next year

[Kevin A. <al...@se...>]

This message is probably a bit premature, but I was thinking about=20
travel and Python conferences for next year, so I thought I would share=20=

my plans. Since I expect PythonCard 1.0 to be finished this winter,=20
once wxPython 2.6 is released, I thought next year would be a good time=20=

to do some PythonCard promotion and training. What I'm planning to do=20
is submit PythonCard talks and tutorials to PyCon and Python UK and=20
OSCON. My proposals will probably be intros, so if anyone wants to make=20=

submissions that touch on more advanced topics, specific tools, or=20
applications they've built with PythonCard, I expect those would also=20
make for interesting talks. I wouldn't mind seeing some submissions for=20=

intros to Python and GUI programming that just happen to use PythonCard=20=

as the learning platform. ;-)

Even if my submissions aren't accepted, I will attend the conferences=20
and if there is interest, I'll also do a PythonCard BOF and/or coding=20
sprint. I've added a wiki page in case you plan to attend some of the=20
Python conferences next year and you want to add your name.

http://wiki.wxpython.org/index.cgi/PythonCardConferences

PyCon 2005 - March 23-25, 2005, George Washington University, DC (same=20=

location as last two years)
Sprints will be taking place on the weekend after the conference, on=20
March 26 and 27.

Python UK Conference - April 20-23, 2005, Randolph Hotel, Oxford
http://www.accu.org/conference/
The Python track hasn't been officially announced, but there will be=20
one and the word should go out in the few weeks.
I hope to do some vacation travel in the UK as well.

EuroPython - June 27 - July 1, 2005, G=F6teborg, Sweden
http://www.europython.org/
I haven't made a decision about EuroPython yet.

OSCON 2005 - date and location unannounced

West Coast Python conference - unknown
This year we had VanPy in Vancouver, BC after OSCON and I won't be=20
surprised if there is a repeat of VanPy in 2005 or perhaps a conference=20=

that combines SciPy and more general topics, sort of a West Coast=20
PyCon.

ka=

Re: [Pythoncard-users] wxSafeYield and findfiles

[Kevin A. <al...@se...>]

On Oct 5, 2004, at 2:19 PM, Alex Tweedly wrote:

>
>  Two questions ....
>
>  1. Is this a bug ?
>  I think there's a bug in that findfiles only does a yield when it=20
> successfully finds the string that you're searching for. If you do a=20=

> findfiles for some string that never occurs, the window is=20
> non-responsive until the search is complete.
>
>  The "inner loop" is
> =A0=A0=A0=A0=A0=A0=A0 for dir in self.dirpattern.split(';'):
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for filename in util.dirwalk(dir, =
patterns, self.recurse):
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if =
self.SearchFile(filename):
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 found +=3D =
1
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
self.statusBar.text =3D "Files found: %d" % found
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if =
self.stopSearching:
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
break
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
wx.SafeYield(self)
>
>
> I think the wx.SafeYield(self) should be outside the "if" block, so=20
> that it occurs for each file.

Fixed

>  2. What's the best way to protect yourself from recursive SafeYield=20=

> calls ?
>  In this case it would be easy enough - just add a flag (or re-use=20
> StopSearching) which is set at the start of the search, and reset at=20=

> the (normal) end; then the menu handler can check for a search already=20=

> in progress, and avoid starting another.=A0 Since SafeYield is only=20
> called within the search, this would fix it for findfiles.

That should have been a wx.SafeYield(self, True) call, the second arg=20
is yieldIfNeeded.

>  But in the general case, there could be SafeYield calls within many=20=

> different processing loops. Is there a way to tell if you are "already=20=

> yielded" ?=A0
>
>  (btw - is wx.SafeYield" documented somewhere ? )
>

wx.SafeYield is a wxPython method, so it is documented in the new=20
wxPython-specific docs, but you can also look at the help for it in the=20=

shell, just type wx.SafeYield( and it should popup. It is a bit=20
confusing to know when to use wx.Yield, wx.SafeYield, or=20
wx.YieldIfNeeded. In the case of findfiles you want to be able to click=20=

a Cancel button to end the search, so I added one of those as well as=20
be able to start viewing a file or make other changes before the search=20=

of all of the files is done so wx.SafeYield seems like the right choice=20=

and setting the yieldIfNeeded flag to True should prevent a recursive=20
call problem. That's about as far as my knowledge goes, so further=20
questions should go to wxPython-users.

ka

[Pythoncard-users] Code Editor using tabbed notebook

[Alex T. <al...@tw...>]

For anyone working from CVS, I've checked in an initial version of the code 
Editor which uses the tabbed notebook to open multiple source files, 
instead of opening new windows.

You can find it in tools/oneEditor/tabcodeEditor.py

It also incorporates the experimental drop-down menus for components and 
events, previously in codeEditoR.

I'd like to hear of any problems encountered with it, or any suggestions 
for it. Or, indeed, of any successful testing / usage of it.

There is one irritating known problem - when you first open the editor, the 
initial text window opens at a fixed size, instead of getting its size from 
the notebook. This gets fixed if you resize the application window - and 
once you've done that, all subsequent edit pages open correctly and resize 
themselves as needed; it's just the very initial page that is wrong.

There's a todo.txt in that directory with some notes on other things to be 
done - but this is the only real problem I currently know about.

-- Alex Tweedly.

[Pythoncard-users] Rounding Issues

[Daryl F. <fly...@sb...>]

Regarding the rounding issues in the dualaxis program:

Yeah, this program is kind of a hack.  I just figured I'd build up a
multi-axis version to see how it would look.  The rounding errors,
decreasing accuracy, was at least intentional.  I figured that with the
bitmap canvas size of 105 x 105 a few pixels of error wouldn't be a problem
and I thought it would be faster.

After running some benchmarks, it looks like speed is not even close to an
issue (on a 2.8 GHz machine).  So yeah, I'll go change the program.

-Daryl

Re: [Pythoncard-users] the trouble with background position

[Peder P. <pe...@ho...>]

My vote goes for solution 3 but I would add a radio group with 4 choices
['Recorded position', 'Left Top', 'Centered', 'Entered Value']

/Peder

----- Ursprungligt meddelande -----
Från: "Kevin Altis" <al...@se...>
Till: "pythoncard-Users" <pyt...@li...>
Skickat: den 1 oktober 2004 22:29
Ämne: [Pythoncard-users] the trouble with background position


> I want to stamp out a problem that I keep forgetting to solve with the
> Background position. The problem is that the resourceEditor saves the
> position of the window in the .rsrc.py file, but in general when a
> background is displayed you would want the position to just use the
> default (-1, -1) so the window manager positions the window. Typically
> that would be the top-left of the display or perhaps the center of the
> display for a dialog. However, I can't really tell from querying the
> position of the window whether it is the default position or not, so
> the resourceEditor just saves the position as is and you manually have
> to delete the 'position' attribute from the .rsrc.py file or change it
> to (-1, -1). However, the next time you modify the file in the
> resourceEditor your change is lost.
>
> You can always override the position manually in your on_initialize
> handler or another method and in fact most of the tools that save
> configuration information do just that. The position specified for all
> backgrounds can also be overridden by sticking a a property into your
> pythoncard_config.txt file such as:
>
> 'defaultBackgroundPosition':(5, 5),
>
> In fact, I have had a line like that in my config from the early days
> of PythonCard, which is why I don't notice all the backgrounds that
> have their position set to the middle of the screen or worse, off the
> right edge of the screen because of where someone had last edited the
> position in the resourceEditor. This is not a general solution to the
> problem though and in fact I should probably remove that attribute
> support from the config.
>
> So, I can see a few solutions to the position problem.
>
> 1. No longer save the background position attribute in the
> resourceEditor.
>
> If you want a specific position, then that would explicitly need to be
> set in your code or manually added to the .rsrc.py file. For simplicity
> sake, this idea appeals to me the most. All existing .rsrc.py files in
> the samples and tools where a 'position' has been saved, but shouldn't
> have one, will be manually edited to get rid of the 'position' line.
> The downside is that if you do want to have a position in the .rsrc.py
> file, then whenever you edit the .rsrc.py file with the resourceEditor
> that position will be lost.
>
> I might be able to add some code to the resourceEditor that only saves
> the position if it is explicitly set by the user in the .rsrc.py file
> or the background info dialog, but I'll have to ponder on that
> solution.
>
> 2. Add an additional flag to the background on whether to override the
> default position with the position attribute.
>
> This would allow the framework and resourceEditor code to know whether
> to use the default position or not, but it seems a bit perverse to me
> and adds complexity to all operations involving the background
> position.
>
> 3. Change the background info dialog in the resourceEditor so there is
> an explicit checkbox that needs to be checked in order to save the
> position of the background.
>
> This would limit the solution and changes to just the resourceEditor,
> but it could still be a bit strange. The position shown in the dialog
> would probably need to be set manually, since whatever position you are
> editing the window probably doesn't reflect where you want the
> background or dialog to show up when the application is run. This
> solution has some additional complications since I would probably still
> need to save something with the .rsrc.py or have a general
> resourceEditor preference for the option.
>
> There are probably some other solutions, but again at this point I lean
> toward just not saving the position from the resourceEditor. Feel free
> to reply with your opinions and I'll make a change early next week so
> the change makes it into release 0.8.1.
>
> Time to go and find a view in Portland of the plume from Mt. St. Helens
> :)
>
> http://story.news.yahoo.com/news?tmpl=story&cid=585&e=1&u=/nm/20041001/
> sc_nm/environment_volcano_dc
>
> ka
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] PythonCard CVS version setup problem?

[Kevin A. <al...@se...>]

This is the problem reported the other day. You don't have NumPy  
installed on your machine, so the underlying FloatCanvas fails to  
import correctly and the component is not checking for this error right  
now. I went ahead and checked in a fix but for now just rename  
PythonCard/components/floatcanvas.py to floatcanvas.txt or something  
like that so the resourceEditor doesn't attempt to load it. The fix  
should show up on the anonymous cvs server sometime later today.

ka
On Oct 2, 2004, at 8:10 AM, Ted Campbell wrote:

> I have been using the stable release of PythonCard on a Mac iBook, OS  
> X (10.3). This morning I downloaded via CVS the PythonCard directory  
> and its contents, renamed the old directory (to old.PythonCard), then  
> moved the new directory into the folder where PythonCard was.  
> codeEditor works fine, but resourceEditor now runs into serious errors  
> reported in the terminal window as follows:
>
> Traceback (most recent call last):
>  File "//Library/Python/2.3/wx/_core.py", line 10604, in <lambda>
>    lambda event: event.callable(*event.args, **event.kw) )
>  File  
> "/Library/Python/2.3/PythonCard/tools/resourceEditor/ 
> resourceEditor.py", line 85, in on_initialize
>    self.buildComponentsMenu()
>  File  
> "/Library/Python/2.3/PythonCard/tools/resourceEditor/ 
> resourceEditor.py", line 285, in buildComponentsMenu
>    resource.loadComponentModule(name)
>  File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages/PythonCard/resource.py", line 30, in  
> loadComponentModule
>    raise ImportError, message
> ImportError: cannot import module 'floatcanvas
>
> I suspect that this is some kind of setup error. Any clues as to how I  
> can make this work? adv(thanks)ance.
>
> /ted

Re: [Pythoncard-users] Resource editor + spinner component

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On Thu, 30 Sep 2004 14:21:29 -0700, Kevin Altis wrote:

>Okay, I went ahead and checked in a hack for Windows, which seems to 
>work, at least for the default control size on my Win2K box. You can 
>try the change out yourself if you want. Starting on line 472 of 
>resourceEditor.py in cvs I extended the offset workarounds for Windows 
>with the elif t == 'Spinner' block.
>
<SNIP>
>                 elif t == 'Spinner':
>                     # compensate for width of TextCtrl portion of
>                     # compound control - width of arrow buttons
>                     self.startGlobalOffset[0] += target.size[0] - 16

Thanks...added that here and it works a treat. Haven't tried changing
font sizes, etc. to see what happens, as mentioned in your previous message.

Neil

[Pythoncard-users] PythonCard CVS version setup problem?

[Ted C. <te...@Te...>]

I have been using the stable release of PythonCard on a Mac iBook, OS X 
(10.3). This morning I downloaded via CVS the PythonCard directory and 
its contents, renamed the old directory (to old.PythonCard), then moved 
the new directory into the folder where PythonCard was. codeEditor works 
fine, but resourceEditor now runs into serious errors reported in the 
terminal window as follows:

Traceback (most recent call last):
  File "//Library/Python/2.3/wx/_core.py", line 10604, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
  File 
"/Library/Python/2.3/PythonCard/tools/resourceEditor/resourceEditor.py", 
line 85, in on_initialize
    self.buildComponentsMenu()
  File 
"/Library/Python/2.3/PythonCard/tools/resourceEditor/resourceEditor.py", 
line 285, in buildComponentsMenu
    resource.loadComponentModule(name)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PythonCard/resource.py", 
line 30, in loadComponentModule
    raise ImportError, message
ImportError: cannot import module 'floatcanvas

I suspect that this is some kind of setup error. Any clues as to how I 
can make this work? adv(thanks)ance.

/ted

[Pythoncard-users] Re: multicolumn questions

[Kevin A. <al...@se...>]

On Oct 1, 2004, at 6:08 PM, Arthur Elsenaar wrote:

> Hi Kevin,
>
> asking you directly instead of the list, as my subscription email 
> account has ISP problems.
>
> Anyway, with the multicolumnlist, I like to find an item on string in 
> the list and remove it. I see wxPython has methods to do so, but how 
> can I use wx methods directly? Other wishes I have, but less 
> important; setting item and background colors, disabling the 
> horizontal scrollbar.
>
> Also I notice that assigning a list to .items frequently after each 
> other, the control has redrawing problems (OS X). So I like to work on 
> a specific item, hence my questions.

I have actually done very little with MultiColumnList, so I'm not as 
well versed with it as other components. In fact, IIRC the supplied 
wrapper was originally done by by William Volkman and I've just added 
onto it a bit and done a few workarounds as PythonCard and wxPython 
have changed. However, all PythonCard components are subclasses of 
wxPython controls, so in general you can just use the underlying 
wxPython methods if there isn't an equivalent PythonCard wrapper 
method. If you want to see the methods in the shell, then you'll want 
to toggle autoCompleteWxMethods, which by default is set to False, so 
only mixedCase method names are shown.

 >>> shell.autoCompleteWxMethods = True

Wasn't there a question on the list not too long ago about setting item 
colors, maybe someone else that has used MultiColumnList more than I 
can chime in here.

If you run into problems with the update speed, you might consider 
calling the Freeze() method before you start your manipulations and 
call Thaw() afterwards to avoid screen updates of the component while 
you are changing a bunch of items.

> Thanks.
>
> Arthur
> ps: is there an indeterminate progress indicator? I don't see how to 
> do this with the progressbar as normally can be done on OS X to set it 
> to barberpole mode.

I don't know offhand. This might be a good question for the 
wxPython-Mac mailing list or wxPython-users.

ka

[Pythoncard-users] the trouble with background position

[Kevin A. <al...@se...>]

I want to stamp out a problem that I keep forgetting to solve with the  
Background position. The problem is that the resourceEditor saves the  
position of the window in the .rsrc.py file, but in general when a  
background is displayed you would want the position to just use the  
default (-1, -1) so the window manager positions the window. Typically  
that would be the top-left of the display or perhaps the center of the  
display for a dialog. However, I can't really tell from querying the  
position of the window whether it is the default position or not, so  
the resourceEditor just saves the position as is and you manually have  
to delete the 'position' attribute from the .rsrc.py file or change it  
to (-1, -1). However, the next time you modify the file in the  
resourceEditor your change is lost.

You can always override the position manually in your on_initialize  
handler or another method and in fact most of the tools that save  
configuration information do just that. The position specified for all  
backgrounds can also be overridden by sticking a a property into your  
pythoncard_config.txt file such as:

'defaultBackgroundPosition':(5, 5),

In fact, I have had a line like that in my config from the early days  
of PythonCard, which is why I don't notice all the backgrounds that  
have their position set to the middle of the screen or worse, off the  
right edge of the screen because of where someone had last edited the  
position in the resourceEditor. This is not a general solution to the  
problem though and in fact I should probably remove that attribute  
support from the config.

So, I can see a few solutions to the position problem.

1. No longer save the background position attribute in the  
resourceEditor.

If you want a specific position, then that would explicitly need to be  
set in your code or manually added to the .rsrc.py file. For simplicity  
sake, this idea appeals to me the most. All existing .rsrc.py files in  
the samples and tools where a 'position' has been saved, but shouldn't  
have one, will be manually edited to get rid of the 'position' line.  
The downside is that if you do want to have a position in the .rsrc.py  
file, then whenever you edit the .rsrc.py file with the resourceEditor  
that position will be lost.

I might be able to add some code to the resourceEditor that only saves  
the position if it is explicitly set by the user in the .rsrc.py file  
or the background info dialog, but I'll have to ponder on that  
solution.

2. Add an additional flag to the background on whether to override the  
default position with the position attribute.

This would allow the framework and resourceEditor code to know whether  
to use the default position or not, but it seems a bit perverse to me  
and adds complexity to all operations involving the background  
position.

3. Change the background info dialog in the resourceEditor so there is  
an explicit checkbox that needs to be checked in order to save the  
position of the background.

This would limit the solution and changes to just the resourceEditor,  
but it could still be a bit strange. The position shown in the dialog  
would probably need to be set manually, since whatever position you are  
editing the window probably doesn't reflect where you want the  
background or dialog to show up when the application is run. This  
solution has some additional complications since I would probably still  
need to save something with the .rsrc.py or have a general  
resourceEditor preference for the option.

There are probably some other solutions, but again at this point I lean  
toward just not saving the position from the resourceEditor. Feel free  
to reply with your opinions and I'll make a change early next week so  
the change makes it into release 0.8.1.

Time to go and find a view in Portland of the plume from Mt. St. Helens  
:)

http://story.news.yahoo.com/news?tmpl=story&cid=585&e=1&u=/nm/20041001/ 
sc_nm/environment_volcano_dc

ka

[Pythoncard-users] division operator and rounding issues with calculations and drawing

[Kevin A. <al...@se...>]

I was looking at Daryl's source code in his "PythonCard to the Rescue" 
article and it reminded me about an issue that is probably worth 
mentioning to a broader audience. His new article is at:

http://www.insanitech.com/pythoncard/

The issue can be summarized by the intro to PEP 238.

http://www.python.org/peps/pep-0238.html

"""
     The current division (/) operator has an ambiguous meaning for
     numerical arguments: it returns the floor of the mathematical
     result of division if the arguments are ints or longs, but it
     returns a reasonable approximation of the division result if the
     arguments are floats or complex.  This makes expressions expecting
     float or complex results error-prone when integers are not
     expected but possible as inputs.
"""

If you do much drawing code you find yourself mixing floats and 
integers in calculations and that can lead to unexpected results 
because of the / operator ambiguity. So you have to force it to do 
floating point division by doing an explicit conversion of one of the 
numbers to floating point in the calculation, or instead of using 
integers like 1, use 1.0 which will also give you a floating point 
result. Here's an example in the shell:

 >>> 1 / 2
0
 >>> float(1) / 2
0.5
 >>> 1.0 / 2
0.5

You can force floating point division today by putting

from __future__ import division

at the top of your module, notice the change in the result below after 
doing the import.

 >>> from __future__ import division
 >>> 1 / 2
0.5

This may or may not be a big deal for what you are calculating or 
drawing. In some cases you could find yourself off by a pixel, but 
sometimes the inaccuracy will be much greater. A simple way to check 
would be to calculate both ways and print the results.

In fact I should probably update many of the PythonCard modules to use 
"from __future__ import division" since I know there are a lot of 
places where I convert integer or long arguments to floats.

There is an additional wrinkle to this tale. wxPython is nice in that 
it will automatically convert floating point coordinates to integers or 
longs before the wxWidgets C++ code actually gets them, so you can use 
floating point coordinates internally for the greatest accuracy. But 
you need to be aware that that the conversion truncates the number, 
5.9999999 is still 5 when it is drawn, so you need to do an explicit 
round() if you want the truncated number to to be drawn rounded up. 
This auto-conversion actually applies to all wxPython arguments where 
an int or long is expected and thus applies to PythonCard methods 
wrappers or aliases to wxPython methods. Here is the relevant bit from 
the wxPython migration guide explaining the details.

"""
Before Python 2.3 it was possible to pass a floating point object as a 
parameter to a function that expected an integer, and the 
PyArg_ParseTuple family of functions would automatically convert to 
integer by truncating the fractional portion of the number. With Python 
2.3 that behavior was deprecated and a deprecation warning is raised 
when you pass a floating point value, (for example, calling 
wx.DC.DrawLine with floats for the position and size,) and lots of 
developers using wxPython had to scramble to change their code to call 
int() before calling wxPython methods. Recent changes in SWIG have 
moved the conversion out of PyArg_ParseTuple to custom code that SWIG 
generates. Since the default conversion fragment was a little too 
strict and didn't generate a very meaningful exception when it failed, 
I decided to use a custom fragment instead, and it turned out that it's 
very easy to allow floats to be converted again just like they used to 
be. So, in a nutshell, any numeric type that can be converted to an 
integer is now legal to be passed to SWIG wrapped functions in wxPython 
for parameters that are expecting an integer. If the object is not 
already an integer then it will be asked to convert itself to one. A 
similar conversion fragment is in place for parameters that expect 
floating point values.
"""

ka

Re: [Pythoncard-users] Pythoncard to the rescue

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On Thu, 30 Sep 2004 00:30:53 -0700, Daryl Fox wrote:

>I'm sorry if this is too long a message or if I'm clogging up important
>developer talk, but I'm still stoked at how easy this was put together.  Of
>course I still have a welt from the HV generator and I'm still out a
>microcontroller and LCD from the same, but this made my day.

This was a great message - it gives us Pythoncard (and Python) beginners
some inspiration and hopefully encourages people to persevere when they
see what real-world, practical projects can be achieved. I'm starting to
appreciate how intuitive and fun Python and Pythoncard is (coming from a
C background mainly) and this sort of post helps prove that I'm not being
over-optimistic in thinking I can start moving a lot of my projects over. 

>Kevin, I know you spend a lot of time answering simple (repetitive?)
>questions on this list ("How do I colour items in a list?") but thank you
>very much for all your hard work.

Seconded (from someone likely to be asking the simple questions).

Neil

Re: [Pythoncard-users] Help with TextArea

[Kevin A. <al...@se...>]

On Sep 26, 2004, at 12:23 PM, Gordon Webster wrote:

> Dear Pythoncard BB
>
> I have created a TextArea control in my app, it
> automatically has a vertical scroll bar but the text
> is too wide for the control. How do I tell it to
> include a horizontal scroll bar?
>
> I still don't understand how i get at the wx level of
> a given pythoncard control - what is the hook?
>
> I tried suff like e.g.
> self.components.myTextArea.style = wx.HSCROLL.
>
> Any help would be greatly appreciated. There are no
> horizontal scrollbars in any of the sample apps.
>
Alex has checked in changes to the TextArea component and 
resourceEditor that adds a horizontalScrollbar attribute.

We still need to address the generic issue of supporting optional 
styles for all components, but I guess we'll put that off until after 
release 0.8.1.

ka

Re: [Pythoncard-users] PythonCard 0.8.1 on Windows XP Problem

[Michael R. <MRe...@be...>]

Kevin,

I apologize for the delay on this one...

Your pointers helped me fix the problem.=20

When I ran:
>>> from PythonCard.components import floatcanvas

I received some additional information indicating that floatcanvas could =
not
import numarray, and thus would not load.  Once I made numarray available, =
*POOF* all the=20
symtoms I previously saw went away.

Thanks for the help,

Michael



>>> "Kevin Altis" <al...@se...> 9/28/2004 11:03:12 AM >>>
On Sep 28, 2004, at 8:50 AM, Michael Redmond wrote:

> I have checked out PythonCard 0.8.1 from CVS, and I consistently get =20
> the following error message when I run resourceEditor.  resourceEditor =
=20
> actually loads, but the component menu is blank:
>
> Traceback (most recent call last):
>   File "C:\BigSnake\lib\site-packages\wx\_core.py", line 10673, in =20
> <lambda>
>     lambda event: event.callable(*event.args, **event.kw) )
>   File =20
> "C:\BigSnake\Lib\site-=20
> packages\PythonCard\tools\resourceEditor\resourceEd
> itor.py", line 85, in on_initialize
>     self.buildComponentsMenu()
>   File =20
> "C:\BigSnake\Lib\site-=20
> packages\PythonCard\tools\resourceEditor\resourceEd
> itor.py", line 285, in buildComponentsMenu
>     resource.loadComponentModule(name)
>   File "C:\BigSnake\Lib\site-packages\PythonCard\resource.py", line =20
> 30, in loadC
> omponentModule
>     raise ImportError, message
> ImportError: cannot import module 'floatcanvas
>
> I am using python 2.3.4 and wxPython 2.5.2.8 for Python 2.3
>
> I checked out PythonCard from CVS, and installed from the windows =20
> binary file created by this command:
> python setup.py --bdist_wininst
>
> Any ideas?  I have uninstalled python, wxPython and PythonCard and =20
> installed into a new location.  Module floatcanvas does live in =20
> several locations in under my Python installation:
>
> ..\site-packages\PythonCard\components
> ..\site-packages\PythonCard\samples
> ..\site-packages\PythonCard\samples\floatCanvasTest
> ..\site-packages\PythonCard\build\lib\Pythoncard\components
> ..\site-packages\wx\lib
> ..\site-packages\wx\demo
> ..\site-packages\wx\lib\floatcanvas
> ..\site-packages\wxPython\lib
>
> To ask a very Newbie question, when an import statement is made, how =20
> does python know where to look for the module?  Could I possibly have =
=20
> a path problem?
>
> I did not have this problem when I was using the 0.8 windows binary =20
> distro of PythonCard from sourceforge.net

Hmm, I'm not seeing that problem on either my Windows or Mac box. The =20
PythonCard/components/floatcanvas.py module does its import of the =20
wxPython FloatCanvas class as

from wx.lib.floatcanvas import FloatCanvas as FCanvas

in order to avoid name collision problems. In resource.py it should be =20
attempting to load the component from the PythonCard/components =20
directory and for some reason on your box that is causing an exception. =
=20
Does the floatCanvasTest sample also fail?

This won't be exactly the same, but start Python and at the >>> prompt =20
type

from PythonCard.components import floatcanvas

and see if that also throws an exception. How about if you do that from =
=20
the codeEditor shell? Does it make any difference what directory you =20
start in if you run from the command-line?

You can check your path that Python uses to import modules and packages =
=20
with the following lines in the shell:
import sys
sys.path

Is anyone else working from cvs seeing this problem?!

BTW, there is a problem with the actual wx.lib.floatcanvas module since =
=20
Chris used the method name Move when he shouldn't have. It has been =20
changed to MoveImage along with the call to Move in the code, but that =20
isn't in wxPython 2.5.2.8, so you would have to change it yourself.

If nothing else works, I suggest simply renaming =20
components/floatcanvas.py to floatcanvas.txt or something like that so =20
that the resourceEditor doesn't attempt to import it until we get this =20
problem figured out.

ka

Re: [Pythoncard-users] Resource editor + spinner component

[Kevin A. <al...@se...>]

Okay, I went ahead and checked in a hack for Windows, which seems to 
work, at least for the default control size on my Win2K box. You can 
try the change out yourself if you want. Starting on line 472 of 
resourceEditor.py in cvs I extended the offset workarounds for Windows 
with the elif t == 'Spinner' block.

                 elif ['Gauge', 'StaticLine'].count(t):
                     self.startGlobalOffset = [self.startGlobalOffset[0] 
+ wx.SystemSettings.GetMetric(wx.SYS_BORDER_X),
                         self.startGlobalOffset[1] + 
wx.SystemSettings.GetMetric(wx.SYS_BORDER_Y)]
                 elif t == 'Spinner':
                     # compensate for width of TextCtrl portion of
                     # compound control - width of arrow buttons
                     self.startGlobalOffset[0] += target.size[0] - 16

ka
On Sep 30, 2004, at 8:53 AM, Kevin Altis wrote:

> On Sep 30, 2004, at 4:35 AM, XXXXXXXXXXX wrote:
>
>> I've noticed a very small bug when trying to drag the spinner control
>> around in the resource editor with Pythoncard 0.8 - could somebody try
>> and replicate this on their installation? It affects my Windows NT
>> machine but not the Mac OSX version.
>>
>> It doesn't seem to be possible to click on the left-hand part of the
>> spinner because that's the text field which grabs the focus, so you 
>> need
>> to click on the right-hand side (around the up-down buttons). That's 
>> OK.
>> The problem is that the outline that appears when you click on the 
>> right-
>> hand side of the component 'jumps' so that you suddenly find yourself
>> with the outline extending out to the right of the cursor, as if 
>> you've
>> actually grabbed it on the left-hand side....
>>
>> ...hmmm...I don't think I'm explaining this very well. Like showing
>> pictures on the radio :-)
>>
>> Like I said, a very small issue. It does make moving the component 
>> small
>> distances via dragging quite tricky though when the component jumps to
>> the right and you then need to drag it back left again before letting 
>> go,
>> though you can always use the position attribute for fine adjustments.
>>
>> Neil
>
> This is a known issue and there isn't much if anything I can do about 
> it. The problem is that AFAIK on Windows the underlying wxWidgets 
> control is a compound control made up a TextCtrl and SpinCtrl. In 
> general, wxWidgets does not mask or translate events so that the 
> compound controls behave as a single entity, except to set the event 
> object, but rather just pass the low-level events like keyDown, 
> mouseDown, and mouseDrag. That causes offsets to generally be wrong, 
> but also causes behavior problems like you're experiencing. Since 
> almost no projects except PythonCard are interested in the type of 
> direct manipulation dragging that PythonCard uses in the 
> resourceEditor, there isn't much incentive at the wxWidgets/wxPython 
> level to "fix" these issues. Pretty much everyone else is using 
> sizer-based layouts and even in the GUI layout tools you are never 
> allowed to select and drag controls but instead have to build layouts 
> by nesting sizers and controls...
>
> With release 0.8.1 there is a workaround since you can use the arrow 
> keys to move the component around. I may also be able to write some 
> workaround code to handle the offset myself for dragging under 
> Windows, but it will be a bit of a hack and might not work all the 
> time depending on default font sizes and such.
>
> ka

Re: [Pythoncard-users] Resource editor + spinner component

[Kevin A. <al...@se...>]

On Sep 30, 2004, at 4:35 AM, XXXXXXXXXXX wrote:

> I've noticed a very small bug when trying to drag the spinner control
> around in the resource editor with Pythoncard 0.8 - could somebody try
> and replicate this on their installation? It affects my Windows NT
> machine but not the Mac OSX version.
>
> It doesn't seem to be possible to click on the left-hand part of the
> spinner because that's the text field which grabs the focus, so you 
> need
> to click on the right-hand side (around the up-down buttons). That's 
> OK.
> The problem is that the outline that appears when you click on the 
> right-
> hand side of the component 'jumps' so that you suddenly find yourself
> with the outline extending out to the right of the cursor, as if you've
> actually grabbed it on the left-hand side....
>
> ...hmmm...I don't think I'm explaining this very well. Like showing
> pictures on the radio :-)
>
> Like I said, a very small issue. It does make moving the component 
> small
> distances via dragging quite tricky though when the component jumps to
> the right and you then need to drag it back left again before letting 
> go,
> though you can always use the position attribute for fine adjustments.
>
> Neil

This is a known issue and there isn't much if anything I can do about 
it. The problem is that AFAIK on Windows the underlying wxWidgets 
control is a compound control made up a TextCtrl and SpinCtrl. In 
general, wxWidgets does not mask or translate events so that the 
compound controls behave as a single entity, except to set the event 
object, but rather just pass the low-level events like keyDown, 
mouseDown, and mouseDrag. That causes offsets to generally be wrong, 
but also causes behavior problems like you're experiencing. Since 
almost no projects except PythonCard are interested in the type of 
direct manipulation dragging that PythonCard uses in the 
resourceEditor, there isn't much incentive at the wxWidgets/wxPython 
level to "fix" these issues. Pretty much everyone else is using 
sizer-based layouts and even in the GUI layout tools you are never 
allowed to select and drag controls but instead have to build layouts 
by nesting sizers and controls...

With release 0.8.1 there is a workaround since you can use the arrow 
keys to move the component around. I may also be able to write some 
workaround code to handle the offset myself for dragging under Windows, 
but it will be a bit of a hack and might not work all the time 
depending on default font sizes and such.

ka

Re: [Pythoncard-users] Pythoncard to the rescue

[Kevin A. <al...@se...>]

On Sep 30, 2004, at 12:30 AM, Daryl Fox wrote:

> I just wanted to drop a quick (well, maybe not so quick) note of 
> thanks to
> Kevin and friends for making such a great tool.

This is very cool! Thank you for proving that the framework and tool 
enable people to rapidly solve problems like that which is exactly what 
it is supposed to do. Very cool.

> Yesterday a package of two Memsic 2125 Accelerometers arrived in the 
> mail
> and I needed to check them out.  I had intended to write a quick 
> program on

<snip>

When I saw "accelerometer" I instantly thought, wow, maybe PythonCard 
is being used to test components being stuck up on Mt. St. Helens. ;-) 
I live in Portland, so people are naturally interested in the little 
quakes and dome growth.

I guess this is what you were testing?

http://www.parallax.com/detail.asp?product_id=28017

You realize of course that if you write a weblog that you have to make 
a post and include the relevant pictures :) If you don't have one then 
maybe I'll bug you for some additional material and post it on mine 
sometime or start a "PythonCard Success Stories" page on the main site. 
I'll probably tweak the code to use some of the 0.8 conventions and 
classes, but it will still work the same.

I would love to hear other stories like this about what people are 
using PythonCard for, how it has saved them time, etc.

ka

RE: [Pythoncard-users] Pythoncard to the rescue

[Heimburger, R. P <rph...@ba...>]

I second that!


Ralph Heimburger=20
Babcock & Wilcox Enterprise Systems
330-860-1858


-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...] On Behalf Of Daryl
Fox
Sent: Thursday, September 30, 2004 3:31 AM
To: pyt...@li...
Subject: [Pythoncard-users] Pythoncard to the rescue

Hello all,

I just wanted to drop a quick (well, maybe not so quick) note of thanks
to
Kevin and friends for making such a great tool.

Yesterday a package of two Memsic 2125 Accelerometers arrived in the
mail
and I needed to check them out.  I had intended to write a quick program
on
my basic stamp just to verify that they work.  However, due to an
accident
involving a high voltage generator, the basic stamp and my LCD it looked
like I was out of luck.  I had access to a number of other micro
controllers, but no other LCD that wasn't hard wired into another
project.
And hey, I wanted it to look nice too. :)

I decided to give pythoncard a go since all that I really needed was a
front
end to display some data.  I hacked together a little program for the
Athena
uC (small stamp clone) that just measures the pulse width on one of the
2125's outputs (two axis may come later) and dumps it to the serial port
connected to my computer.
--- test2125 ---
' Memsic 2125 Test

dim   T1     ' 2125 pulse width
const Ser  5 ' Serial pin
const Xout 0 ' Input from 2125

PULSEINSCALE =3D 4

input Xout
output Ser

loop:
   pulsein Xout, 3, T1
   serout Ser, T1
   goto loop

Then I tossed together a quick front end using pythoncard:
--- read2125.rsrc.py ---
{'application':{'type':'Application',
          'name':'Template',
    'backgrounds': [
    {'type':'Background',
          'name':'bgTemplate',
          'title':'Memsic 2125 Tester',
          'position':(37, 81),
          'size':(400, 207),

        'menubar': {'type':'MenuBar',
         'menus': [
             {'type':'Menu',
             'name':'menuFile',
             'label':'&File',
             'items': [
                  {'type':'MenuItem',
                   'name':'menuFileExit',
                   'label':'E&xit\tAlt+X',
                   'command':'exit',
                  },
              ]
             },
         ]
     },
         'components': [

{'type':'StaticText',
    'name':'labelPos2',
    'position':(370, 75),
    'text':'2g',
    },

{'type':'StaticText',
    'name':'labelPos1',
    'position':(280, 75),
    'text':'1g',
    },

{'type':'StaticText',
    'name':'label0',
    'position':(190, 75),
    'text':'0g',
    },

{'type':'StaticText',
    'name':'labelNeg1',
    'position':(95, 75),
    'text':'-1g',
    },

{'type':'StaticText',
    'name':'labelNeg2',
    'position':(5, 75),
    'text':'-2g',
    },

{'type':'TextField',
    'name':'Force',
    'position':(145, 105),
    'alignment':'center',
    'editable':False,
    },

{'type':'StaticText',
    'name':'TitleText',
    'position':(140, 15),
    'text':'Force (1g =3D 9.81m/s^2)',
    },

{'type':'Gauge',
    'name':'Gauge',
    'position':(10, 40),
    'size':(370, 28),
    'layout':'horizontal',
    'max':4000,
    'value':2000,
    },

] # end components
} # end background
] # end backgrounds
} }

--- read2125.py ---
#!/usr/bin/python

"""
__version__ =3D "$Revision: 1.5 $"
__date__ =3D "$Date: 2004/04/30 16:26:12 $"
"""

from PythonCard import model, dialog
from wxPython import wx
import accel

class MyBackground(model.Background):
   def on_initialize(self, event):
      self.Device =3D accel.Memsic()
      if not self.Device.Alive:
         dialog.alertDialog(self, 'ERROR: Cannot connect to device',
                                  'Serial Error')
         self.close()

      self.Timer =3D wx.wxTimer(self.components.Force, -1)
      self.Timer.Start(100) # 100 ms updates

   def on_Force_timer(self, event):
      F =3D self.Device.GetForce()
      if F !=3D None:
         # Note: The gauge is scaled by 1000 because it needs
         #       integers for value.
         self.components.Gauge.value =3D int((F + 2.0) * 1000)
         self.components.Force.text =3D '%0.3f' % F
      else:
         self.components.Force.text =3D 'N/A'

   def on_close(self, event):
      # Deamonize the thread to avoid this?
      self.Device.Stop()
      event.Skip()

if __name__ =3D=3D '__main__':
   app =3D model.Application(MyBackground)
   app.MainLoop()

And an interface class:
--- accel.py ---
import serial
import Queue
import threading

class Memsic:
   def __init__(self):
      # Brain dead serial setup
      self.Ser =3D serial.Serial(0)
      self.Ser.baudrate =3D 9600
      self.Ser.timeout =3D 1
      self.Alive =3D False
      try:
         self.Ser.open() # COM1, 9600,N,8,1
      except serial.SerialException:
         # Exception catching has not been tested
         return

      # Probably don't need to do this.  May be easier just
      # to read as needed.  Don't worry about overflow.  Oh
      # well, threads are fun.
      self.RxQueue =3D Queue.Queue()
      self.Alive =3D True
      Thread =3D threading.Thread(target=3Dself.Reader)
      Thread.start()

      # Set this to the number of seconds per unit for the T1
      # pulse width.  For the BS2 it should be 2us (2e-6) but
      # may be different by default on other uC systems.
      self.Units =3D 32e-6  # 32us for Athena
   def Stop(self):
      self.Alive =3D False
   def Reader(self):
      while self.Alive:
         Data =3D self.Ser.read(1)
         # Abusing the empty() method
         if Data and self.RxQueue.empty():
            Value =3D ord(Data)
            if Value < 0 or Value > 255:
               continue
            self.RxQueue.put(Value)
   def GetForce(self):
      try:
         Value =3D self.RxQueue.get(True, 0.250)
      except Queue.Empty:
         return None
      return self.F(Value)
   def F(self, Value):
      T1 =3D Value * self.Units
      # Assume that T2 =3D 10ms.  For greater accuracy, we should
      # measure this every N cycles or so.  This will only be
      # accurate at 25C (if properly calibrated).
      T2 =3D 10e-3
      return ((T1/T2) - 0.5) * 8

The whole process took under an hour and looks (IMHO) great.  Tip the
board
with the accelerometer and watch the pretty pictures.

I'm sorry if this is too long a message or if I'm clogging up important
developer talk, but I'm still stoked at how easy this was put together.
Of
course I still have a welt from the HV generator and I'm still out a
microcontroller and LCD from the same, but this made my day.

Kevin, I know you spend a lot of time answering simple (repetitive?)
questions on this list ("How do I colour items in a list?") but thank
you
very much for all your hard work.

-Daryl



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] Resource editor + spinner component

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

I've noticed a very small bug when trying to drag the spinner control
around in the resource editor with Pythoncard 0.8 - could somebody try
and replicate this on their installation? It affects my Windows NT
machine but not the Mac OSX version.

It doesn't seem to be possible to click on the left-hand part of the
spinner because that's the text field which grabs the focus, so you need
to click on the right-hand side (around the up-down buttons). That's OK.
The problem is that the outline that appears when you click on the right-
hand side of the component 'jumps' so that you suddenly find yourself
with the outline extending out to the right of the cursor, as if you've
actually grabbed it on the left-hand side....

...hmmm...I don't think I'm explaining this very well. Like showing
pictures on the radio :-)

Like I said, a very small issue. It does make moving the component small
distances via dragging quite tricky though when the component jumps to
the right and you then need to drag it back left again before letting go,
though you can always use the position attribute for fine adjustments.

Neil