Menu
▾
▴
pythoncard-users — PythonCard Users and Developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(116) |
Sep
(146) |
Oct
(78) |
Nov
(69) |
Dec
(70) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(188) |
Feb
(142) |
Mar
(143) |
Apr
(131) |
May
(97) |
Jun
(221) |
Jul
(127) |
Aug
(89) |
Sep
(83) |
Oct
(66) |
Nov
(47) |
Dec
(70) |
| 2003 |
Jan
(77) |
Feb
(91) |
Mar
(103) |
Apr
(98) |
May
(134) |
Jun
(47) |
Jul
(74) |
Aug
(71) |
Sep
(48) |
Oct
(23) |
Nov
(37) |
Dec
(13) |
| 2004 |
Jan
(24) |
Feb
(15) |
Mar
(52) |
Apr
(119) |
May
(49) |
Jun
(41) |
Jul
(34) |
Aug
(91) |
Sep
(169) |
Oct
(38) |
Nov
(32) |
Dec
(47) |
| 2005 |
Jan
(61) |
Feb
(47) |
Mar
(101) |
Apr
(130) |
May
(51) |
Jun
(65) |
Jul
(71) |
Aug
(96) |
Sep
(28) |
Oct
(20) |
Nov
(39) |
Dec
(62) |
| 2006 |
Jan
(13) |
Feb
(19) |
Mar
(18) |
Apr
(34) |
May
(39) |
Jun
(50) |
Jul
(63) |
Aug
(18) |
Sep
(37) |
Oct
(14) |
Nov
(56) |
Dec
(32) |
| 2007 |
Jan
(30) |
Feb
(13) |
Mar
(25) |
Apr
(3) |
May
(15) |
Jun
(42) |
Jul
(5) |
Aug
(17) |
Sep
(6) |
Oct
(25) |
Nov
(49) |
Dec
(10) |
| 2008 |
Jan
(12) |
Feb
|
Mar
(17) |
Apr
(18) |
May
(12) |
Jun
(2) |
Jul
(2) |
Aug
(6) |
Sep
(4) |
Oct
(15) |
Nov
(45) |
Dec
(9) |
| 2009 |
Jan
(1) |
Feb
(3) |
Mar
(18) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(13) |
Aug
(2) |
Sep
(1) |
Oct
(9) |
Nov
(13) |
Dec
|
| 2010 |
Jan
(2) |
Feb
(3) |
Mar
(9) |
Apr
(10) |
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
(4) |
| 2011 |
Jan
|
Feb
|
Mar
(10) |
Apr
(44) |
May
(9) |
Jun
(22) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dan S. <py...@da...> - 2002-02-22 08:16:24
|
<html>
<head>
</head>
<body>
<br>
<br>
Kevin Altis wrote:<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap="">Has anyone experienced problems trying to figure out which .py file to run<br>with any of the samples?<br></pre>
</blockquote>
Not when I view the file list in list view rather than icon view! :-)<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Once you have more than a single Python script in a directory, knowing which<br>one is the actual application and which files are just support modules<br>becomes an issue. PythonCard programs always have at least two files, the<br>main script such as minimal.py and a resource file like minimal.rsrc.py. The<br>number of files increases as additional support modules, localized resource<br>files, images, sounds, and other data files are added.<br></pre>
</blockquote>
I'd rather see us adopt a convention than a new folder structure myself.
One of the things that always gets in the way of trying to master Java is
the horrendous amount of time one spends figuring out where stuff is. In
PythonCard, it's all right there.<br>
<br>
Maybe, e.g., if we adopted the rule that you should always prefix or suffix
your main launching Python file with app_ or _app? I think Patrick is doing
this already, no?<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Should we add standard sub-directory support to PythonCard to reduce clutter<br>in the main application directory?<br><br>The "clutter" increases once a script is compiled (.pyc) and/or optimized<br>(.pyo) which is something that distutils does by default when it installs a<br>package. Imagine the minimal sample directory containing:<br>.cvsignore, minimal.fr.rsrc.py, minimal.fr.rsrc.pyc, minimal.fr.rsrc.pyo,<br>minimal.py, minimal.pyc, minimal.pyo, minimal.rsrc.py, minimal.rsrc.pyc,<br>minimal.rsrc.pyo, minimal.spec, readme.txt, setup.py, setup.pyc, setup.pyo<br></pre>
</blockquote>
But if this were set up so that minimal.py would become, say, minimal_app.py
or app_minimal.py or even perhaps something more clear and a tad bizarre
such as run_minimal.py. I know we couldn't *enforce* that but we can only
enforce the subdirectory structure by causing things not to work if they're
not put into the right place. For an inventive user, this yet another barrier
to entry.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>It is likely that we will start splitting the samples off into their own zip<br>for each release, partly to avoid the distutils auto-compiles.<br></pre>
</blockquote>
That sounds like it has some value.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>The suggestion has been made in the past that the resource files should be<br>renamed so they don't have a .py extension (.rsrc), but there were arguments<br>in favor of keeping the filenames unchanged as well. If the resource format<br>migrates to XML then there shouldn't be any confusion over the extension,<br>but that isn't going to happen soon.<br></pre>
</blockquote>
I see both sides of this one. If you lose the .py extension then on Windows
Python 2.2, the automatic menu option to edit in IDLE goes away (as does
the winPython "Edit" option that opens WinPython by default). I think the
value of having that capability out-weighs any confusion that might be caused
by rsrc.py file name endings.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>The next thing you need to know is that Python searches for modules and<br>packages to import using sys.path.<br><br>After running minimal.py with the -s (shell) command-line option on my<br>machine, this is what sys.path returns.<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">import sys<br>sys.path<br></pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->['.', '<a class="moz-txt-link-freetext" href="C:\\python\\PythonCardPrototype\\samples\\minimal">C:\\python\\PythonCardPrototype\\samples\\minimal</a>', '<a class="moz-txt-link-freetext" href="c:\\python">c:\\python</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\Pythonwin">C:\\Python21\\Pythonwin</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\win32">C:\\Python21\\win32</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\win32\\Lib">C:\\Python21\\win32\\Lib</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21">C:\\Python21</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\DLLs">C:\\Python21\\DLLs</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\lib">C:\\Python21\\lib</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\lib\\plat-win">C:\\Python21\\lib\\plat-win</a>',<br>'<a class="moz-txt-link-freetext" href="C:\\Python21\\lib\\lib-tk">C:\\Python21\\lib\\lib-tk</
a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\PIL">C:\\Python21\\PIL</a>', '<a class="moz-txt-link-freetext" href="C:\\Python21\\PPM">C:\\Python21\\PPM</a>']<br><br>These are the directories and the order that Python checks for packages and<br>modules when you use the import statement. Your local configuration will<br>probably be similar but different. If we added a directory called 'modules'<br>to a sample like resourceEditor and then added an empty __init__.py file to<br>the 'modules' directory to make the directory a package then any additional<br>Python code the application needed could be put in the 'modules' directory<br>and imported since the current application directory is part of sys.path.<br></pre>
</blockquote>
Again, I don't see this as being such a big problem. I suspect you have bigger
fish to fry, Kevin. This is a problem that nobody has reported or commented
on yet.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>As a test I created separate files for each of the dialog classes used by<br>the resourceEditor: backgroundInfoDialog.py, stackInfoDialog.py, and<br>menuDialog.py, and then moved the scripts and their resource files into the<br>modules directory. I had to update the path each class used to load its<br>resource file, but ignore that for now. I then updated the resourceEditor.py<br>code to import the necessary classes.<br><br>from modules.backgroundInfoDialog import BackgroundInfoDialog<br>from modules.stackInfoDialog import StackInfoDialog<br>from modules.menuDialog import MenuDialog<br></pre>
</blockquote>
More complexity.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>One thing to note is that you don't want the name of the directory to<br>conflict with any standard Python package or module name. While each<br>PythonCard application could have its own directories, it might be easier to<br>understand scripts written by different people if everyone used the same<br>directory structure.<br></pre>
</blockquote>
I think this demonstrates my point: all you are really doing in the end is
shifting complexity from identifying the files to identifying the folders
the files should be in. The hierarchical nature of a file structure inevitably
adds opaqueness to the complexity and for my target audience, that's never
a good thing. The only thing that should be in sub-directories in such a
situation, IMNSHO, is stuff the user can simply ignore.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>When we were discussing localized resource files on the list, the suggestion<br>was made to have a special directory that contains the localized resource<br>files. I still think this is a good idea. I lean towards keeping the main<br>.rsrc.py file and its associated module file in the same directory, but the<br>issue is open for debate.<br></pre>
</blockquote>
Putting the localized resource files in one separate folder will also make
it easy later to do a locale-specific install. The main .rsrc.py file would
always be called that after the installation.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Sounds, images, and data files could be placed in a one or more standard<br>directories.<br></pre>
</blockquote>
This might or might not make sense. I do see that as apps get more and more
complex and we end up with more and more files in the single folder, things
might get edgy. But, these users deal with lots of files at the OS level
all the time. I doubt that will be an issue.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>We don't have to solve this problem now, but we should address it sometime<br>if it is causing confusion, especially for programmers new to Python. If we<br>don't provide standard directory support in the framework, one or more of<br>the samples could show ways of using sub-directories to better organize more<br>complex programs.<br></pre>
</blockquote>
I think this is a good idea! Offer a sort of best-practices recommendation
and teaching on the matter but leave it ulaimately to the individual developer/user
to organize their stuff so it's easy. I suspect down the road very few end
users will be double-clicking Python files; there will be some other launch
mechanism we don't even see yet.<br>
<blockquote type="cite" cite="mid:DGE...@se...">
<pre wrap=""><br>Other suggestions or related issues?<br><br>ka<br><br><br>_______________________________________________<br>Pythoncard-users mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Pyt...@li...">Pyt...@li...</a><br><a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/pythoncard-users">https://lists.sourceforge.net/lists/listinfo/pythoncard-users</a><br><br><br></pre>
</blockquote>
<br>
</body>
</html>
|
|
From: Kevin A. <al...@se...> - 2002-02-20 22:24:06
|
I updated the resourceEditor sample in cvs to use sub-directories to explore how we might use standard sub-directories for organizing PythonCard apps. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp e/samples/resourceEditor/ Since I used os.path.join to build the paths to files explictly, please let me know if the resourceEditor no longer works on your system. ka |
|
From: Patrick K. O'B. <po...@or...> - 2002-02-20 22:11:59
|
I assumed I didn't need to mention this, but I guess I should have. Your suspicions are correct. Zope is compiled for Python 2.1, not 2.2. At least, not yet. So for now you need to launch PyCrust using Python 2.1 in order to be able to import Zope. Otherwise you'll get the dll mismatch error that you got. --- Patrick K. O'Brien Orbtech > There is always an awkward one isn't there. I think I may have > confounded this by running Python 2.2 on my machine (Windows > 2000, Zope 2.5.0, PyCrust 0.7 - from wxPython 2.3.2.1). > > When I add the zope home/lib/python to my path and "import Zope" > I get a pop up stating "The dynamic link library python21.dll > could not be found in the specified path " followed by the > contents of my %PATH%. So, I added "E:\\Work\\Zope\\bin" to my > path as well (the location of python21.dll) but that didn't solve > the problem. I'm presuming that this is because I launch pycrust > using Python 2.2 and that the dlls are somehow incompatible. Or, > I could just be doing something wrong. > > Regards, > Andy > > |
|
From: <an...@ha...> - 2002-02-20 21:50:28
|
On Wed, 20 February 2002, "Patrick K. O'Brien" wrote: > > For anyone who wants to poke around Zope from inside PyCrust, here is an > example of how one starts. Zope must be installed on your machine, but can't > be running at the same time that PyCrust is accessing it. > > >>> import sys > >>> sys.path.insert(1, 'C:\\Zope\\lib\\python') > >>> import Zope > >>> app = Zope.app() > >>> > > The app object is the root of the Zope database. From here you can get to > everything. The easiest way is to drill down into stuff in the namespace > viewer. > > Note that the path you add to the PythonPath (sys.path) needs to match the > location on your machine. The example above happens to match where I have > Zope installed on a Windows machine. The default is for Zope to install > under Program Files. So in that case the line would be: > > >>> sys.path.insert(1, 'C:\\Program Files\\Zope\\lib\\python') > > If you get an error when you import Zope, you've done something wrong. ;-) > > --- > Patrick K. O'Brien > Orbtech > > There is always an awkward one isn't there. I think I may have confounded this by running Python 2.2 on my machine (Windows 2000, Zope 2.5.0, PyCrust 0.7 - from wxPython 2.3.2.1). When I add the zope home/lib/python to my path and "import Zope" I get a pop up stating "The dynamic link library python21.dll could not be found in the specified path " followed by the contents of my %PATH%. So, I added "E:\\Work\\Zope\\bin" to my path as well (the location of python21.dll) but that didn't solve the problem. I'm presuming that this is because I launch pycrust using Python 2.2 and that the dlls are somehow incompatible. Or, I could just be doing something wrong. Regards, Andy |
|
From: Patrick K. O'B. <po...@or...> - 2002-02-20 20:24:41
|
That should work fine. As long as you can import the Zope package, Zope should take care of the rest. The fact that the files are not on your local machine shouldn't matter. I guess I misspoke in my original instructions. It is still true that the Zope server cannot be running. Nor should any other application have the Zope database open. Let me know if you run into a snag. --- Patrick K. O'Brien Orbtech > -----Original Message----- > From: Keith J. Farmer [mailto:kf...@th...] > Sent: Wednesday, February 20, 2002 2:02 PM > To: po...@or...; pycr; Pythoncard > Subject: RE: [PyCrust] Example of Zope in PyCrust > > > What if you've got the zope directory on a foreign machine, mapped to a > local drive? > > ---------- > Keith J. Farmer > kf...@th... > http://www.thuban.org > > > -----Original Message----- > From: Patrick K. O'Brien [mailto:po...@or...] > Sent: Wednesday, February 20, 2002 10:06 > > example of how one starts. Zope must be installed on your machine, but > can't > be running at the same time that PyCrust is accessing it. |
|
From: Keith J. F. <kf...@th...> - 2002-02-20 19:54:47
|
What if you've got the zope directory on a foreign machine, mapped to a local drive? ---------- Keith J. Farmer kf...@th... http://www.thuban.org -----Original Message----- From: Patrick K. O'Brien [mailto:po...@or...] Sent: Wednesday, February 20, 2002 10:06 example of how one starts. Zope must be installed on your machine, but can't be running at the same time that PyCrust is accessing it. |
|
From: Patrick K. O'B. <po...@or...> - 2002-02-20 18:01:18
|
For anyone who wants to poke around Zope from inside PyCrust, here is an example of how one starts. Zope must be installed on your machine, but can't be running at the same time that PyCrust is accessing it. >>> import sys >>> sys.path.insert(1, 'C:\\Zope\\lib\\python') >>> import Zope >>> app = Zope.app() >>> The app object is the root of the Zope database. From here you can get to everything. The easiest way is to drill down into stuff in the namespace viewer. Note that the path you add to the PythonPath (sys.path) needs to match the location on your machine. The example above happens to match where I have Zope installed on a Windows machine. The default is for Zope to install under Program Files. So in that case the line would be: >>> sys.path.insert(1, 'C:\\Program Files\\Zope\\lib\\python') If you get an error when you import Zope, you've done something wrong. ;-) --- Patrick K. O'Brien Orbtech |
|
From: Kevin A. <al...@se...> - 2002-02-20 08:03:26
|
> From: Andy Todd
>
> My latest design dilemma is how to differentiate between enterable and
> display only information in my application.
>
> When I am fetching data into my application from a database some values
> will be directly enterable by the user but others are 'reference' values
> that shouldn't be changed at that time or in that place.
>
> I'm currently putting the enterable data in TextField widgets and my
> unchangeable data in StaticText widgets. But, to differentiate the
> non-updateable StaticText widgets from my actual boilerplate I would
> like them to be different colours.
You can also make TextField widgets non-editable ('editable':0) or disabled
('enabled':0). Non-editable fields don't look any different, but the user
can only copy the text, not change it.
> I would like to specify my colours as default values (say in a module
> level variable in the .py file) which are then picked up in the resource
> file. But I couldn't find a way to do it.
>
> In the first instance I just want to be able to specify a variable
> *somewhere* and reference it in my resource file, e.g.
>
> { ... 'foregroundColor': MYFGCOLOUR ... }
>
> But I don't think there is any way to do this in the current framework -
> or is there? Am I stuck with strings in my resource file that I have to
> do a search and replace for when my fickle nature dictates a
> colour change?
There is no way of doing that kind of replacement automatically the way
resource loading works right now since it does an eval() to turn the whole
file into a dictionary. If we changed the resource loading so that resources
were loaded via a real import then constants could be defined and they would
propogate through the file correctly. That is one scheme we've discussed in
the past and it appeals to me.
> If there is a way to do this, or we can build one into the framework we
> could then provide a user configurable colour scheme, or expand it to a
> full blown skinning system. Which is probably overkill but I thought I
> would mention it anyway.
In the meantime, just add a method to change the colors and then call that
method from your openBackground handler. The method just needs a list of the
relevant components and then it can iterate through the list setting the
foregroundColor.
ka
> Regards,
> Andy
> --
> -----------------------------------------------------------------------
> From the desk of Andrew J Todd esq.
> "So I curtailed my Walpoling activities, sallied forth and infiltrated
> your place of purveyance to negotiate the vending of some cheesy
> comestibles." - Monty Python.
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
|
|
From: Andy T. <an...@ha...> - 2002-02-20 07:50:56
|
My latest design dilemma is how to differentiate between enterable and
display only information in my application.
When I am fetching data into my application from a database some values
will be directly enterable by the user but others are 'reference' values
that shouldn't be changed at that time or in that place.
I'm currently putting the enterable data in TextField widgets and my
unchangeable data in StaticText widgets. But, to differentiate the
non-updateable StaticText widgets from my actual boilerplate I would
like them to be different colours.
So I started to specify all of my 'dynamic' StaticText widget with
'foregroundColor':'blue' and that works a treat. I've also played around
with them as TextField widgets and either will do. But this lead me to
another idea.
I would like to specify my colours as default values (say in a module
level variable in the .py file) which are then picked up in the resource
file. But I couldn't find a way to do it.
In the first instance I just want to be able to specify a variable
*somewhere* and reference it in my resource file, e.g.
{ ... 'foregroundColor': MYFGCOLOUR ... }
But I don't think there is any way to do this in the current framework -
or is there? Am I stuck with strings in my resource file that I have to
do a search and replace for when my fickle nature dictates a colour change?
If there is a way to do this, or we can build one into the framework we
could then provide a user configurable colour scheme, or expand it to a
full blown skinning system. Which is probably overkill but I thought I
would mention it anyway.
Regards,
Andy
--
-----------------------------------------------------------------------
From the desk of Andrew J Todd esq.
"So I curtailed my Walpoling activities, sallied forth and infiltrated
your place of purveyance to negotiate the vending of some cheesy
comestibles." - Monty Python.
|
|
From: Andy T. <an...@ha...> - 2002-02-20 07:33:20
|
Thanks Patrick, works like a charm. Allied with Kevin's post that
PythonCard widgets are direct subclasses of wxPython widgets I played
around and found your advice to be spot on.
To show how it works, fire up a PythonCard application (I used the
minimal sample) and type the following at the shell;
>>> comp['field2']={'type':'Choice', 'name':'field2',
'position':(50,50), 'items':[]}
>>> comp.field2.Append('Value', 'Key')
Repeat the last command as required to populate the pop-down list. Then
select the value you want and do;
>>> comp.field2.GetClientData(comp.field2.GetSelection())
Marvellous.
Of course, in the mean time I've changed my mind. But that is another
post. Not least because I'm sadly lacking places on the project
'leaders' page at ASPN
(http://aspn.activestate.com/ASPN/Mail/Leaders/PythonCard/) ;-)
Regards,
Andy
--
-----------------------------------------------------------------------
From the desk of Andrew J Todd esq.
"So I curtailed my Walpoling activities, sallied forth and infiltrated
your place of purveyance to negotiate the vending of some cheesy
comestibles." - Monty Python.
Patrick K. O'Brien wrote:
> I think what you need to do is use the wxChoice.Append() method, which lets
> you add string/object combinations to the list of choices. (There are
> similar methods in the tree control that I use in the namespace viewer.) The
> string is what gets displayed, the object is accessible through
> wxChoice.GetClientData(), which can be based on which item is selected. So
> you'll probably end up with code something like:
>
> # Not tested!!!
> currentObject = myChoice.GetClientData(myChoice.GetSelection())
>
> It doesn't look like any of this is wrapped by PythonCard at the moment.
> I'll take a look today if I have time. What would be nice is if we could
> make wxChoice look like a Python dictionary (mapping). That should simplify
> access to this sort of thing, especially if we could just pass a
> mapping-type object to the __init__ and have all the items appended
> properly.
>
> Hope that helps.
>
> ---
> Patrick K. O'Brien
> Orbtech
>
>
>>-----Original Message-----
>>From: pyt...@li...
>>[mailto:pyt...@li...]On Behalf Of Andy
>>Todd
>>Sent: Tuesday, February 19, 2002 5:50 AM
>>To: Pythoncard-Users
>>Subject: [Pythoncard-users] Brain Fade
>>
>>
>>Evening all,
>>
>>Its late, but I can't find any examples of what I want to do anywhere.
>>This is a fairly frequent occurrence in the world of relational
>>databases and I've been scratching my head trying to figure out how to
>>represent it in PythonCard.
>>
>>Enough teasing, I have a table which contains keys and descriptions and
>>I want to display the available descriptions in a 'choice' widget. Which
>>is fairly easy. But when the user selects an element in the choice
>>widget I want my code to know the corresponding key value. Is there any
>>way to associate multiple items (say tuples?) with a choice widget?
>>
>>At the moment I'm returning the key-description pairs into a dictionary,
>>so of course it would be nice to just get the key from the description
>>value but I don't know of a way to do this in ordinary Python, unless I
>>am being more of an idiot than usual.
>>
>>I don't think I can associate multiple values with each item in
>>PythonCard (or wxPython for that matter) so I probably need to do this
>>in my program.
>>
>>But, and this is a big but, I don't want to have to iterate through all
>>of the available key-description pairs to find the key I'm looking for
>>based on the value from the choice widget.
>>
>>Any suggestions?
>>
>>Regards,
>>Andy
>>--
>>-----------------------------------------------------------------------
>> From the desk of Andrew J Todd esq.
>>Smiggins Hole 2010 - Unleash the Mongrel
>>
>>
|
|
From: Kevin A. <al...@se...> - 2002-02-19 22:07:53
|
The cvs version of PythonCardPrototype is using direct subclasses of
wxPython controls, so you can use the client data methods if you want to
give that a try.
In general, I would say you are better off creating a second dictionary that
uses the values as keys and the keys as values, assuming the values are
unique, which they probably are if you're displaying them in a Choice
component. I suppose there is a good reason that the descriptions are not
already being used as the keys? How big are the dictionaries?
The brute force method of finding a key based on value looks like this:
>>> d = {1:'one', 2:'two', 3:'three', 4:'four'}
>>> def getKeyByValue(d, value):
... for k in d.items():
... if k[1] == value:
... return k[0]
... return None
...
>>> getKeyByValue(d, 'four')
4
There is probably a clever lambda or iterator that would do a better job,
but that function gets the job done. Is this what you needed?
ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Andy
> Todd
> Sent: Tuesday, February 19, 2002 3:50 AM
> To: Pythoncard-Users
> Subject: [Pythoncard-users] Brain Fade
>
>
> Evening all,
>
> Its late, but I can't find any examples of what I want to do anywhere.
> This is a fairly frequent occurrence in the world of relational
> databases and I've been scratching my head trying to figure out how to
> represent it in PythonCard.
>
> Enough teasing, I have a table which contains keys and descriptions and
> I want to display the available descriptions in a 'choice' widget. Which
> is fairly easy. But when the user selects an element in the choice
> widget I want my code to know the corresponding key value. Is there any
> way to associate multiple items (say tuples?) with a choice widget?
>
> At the moment I'm returning the key-description pairs into a dictionary,
> so of course it would be nice to just get the key from the description
> value but I don't know of a way to do this in ordinary Python, unless I
> am being more of an idiot than usual.
>
> I don't think I can associate multiple values with each item in
> PythonCard (or wxPython for that matter) so I probably need to do this
> in my program.
>
> But, and this is a big but, I don't want to have to iterate through all
> of the available key-description pairs to find the key I'm looking for
> based on the value from the choice widget.
>
> Any suggestions?
>
> Regards,
> Andy
> --
> -----------------------------------------------------------------------
> From the desk of Andrew J Todd esq.
> Smiggins Hole 2010 - Unleash the Mongrel
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
|
|
From: Patrick K. O'B. <po...@or...> - 2002-02-19 15:02:33
|
I think what you need to do is use the wxChoice.Append() method, which lets you add string/object combinations to the list of choices. (There are similar methods in the tree control that I use in the namespace viewer.) The string is what gets displayed, the object is accessible through wxChoice.GetClientData(), which can be based on which item is selected. So you'll probably end up with code something like: # Not tested!!! currentObject = myChoice.GetClientData(myChoice.GetSelection()) It doesn't look like any of this is wrapped by PythonCard at the moment. I'll take a look today if I have time. What would be nice is if we could make wxChoice look like a Python dictionary (mapping). That should simplify access to this sort of thing, especially if we could just pass a mapping-type object to the __init__ and have all the items appended properly. Hope that helps. --- Patrick K. O'Brien Orbtech > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Andy > Todd > Sent: Tuesday, February 19, 2002 5:50 AM > To: Pythoncard-Users > Subject: [Pythoncard-users] Brain Fade > > > Evening all, > > Its late, but I can't find any examples of what I want to do anywhere. > This is a fairly frequent occurrence in the world of relational > databases and I've been scratching my head trying to figure out how to > represent it in PythonCard. > > Enough teasing, I have a table which contains keys and descriptions and > I want to display the available descriptions in a 'choice' widget. Which > is fairly easy. But when the user selects an element in the choice > widget I want my code to know the corresponding key value. Is there any > way to associate multiple items (say tuples?) with a choice widget? > > At the moment I'm returning the key-description pairs into a dictionary, > so of course it would be nice to just get the key from the description > value but I don't know of a way to do this in ordinary Python, unless I > am being more of an idiot than usual. > > I don't think I can associate multiple values with each item in > PythonCard (or wxPython for that matter) so I probably need to do this > in my program. > > But, and this is a big but, I don't want to have to iterate through all > of the available key-description pairs to find the key I'm looking for > based on the value from the choice widget. > > Any suggestions? > > Regards, > Andy > -- > ----------------------------------------------------------------------- > From the desk of Andrew J Todd esq. > Smiggins Hole 2010 - Unleash the Mongrel > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users |
|
From: Andy T. <an...@ha...> - 2002-02-19 11:45:42
|
Evening all, Its late, but I can't find any examples of what I want to do anywhere. This is a fairly frequent occurrence in the world of relational databases and I've been scratching my head trying to figure out how to represent it in PythonCard. Enough teasing, I have a table which contains keys and descriptions and I want to display the available descriptions in a 'choice' widget. Which is fairly easy. But when the user selects an element in the choice widget I want my code to know the corresponding key value. Is there any way to associate multiple items (say tuples?) with a choice widget? At the moment I'm returning the key-description pairs into a dictionary, so of course it would be nice to just get the key from the description value but I don't know of a way to do this in ordinary Python, unless I am being more of an idiot than usual. I don't think I can associate multiple values with each item in PythonCard (or wxPython for that matter) so I probably need to do this in my program. But, and this is a big but, I don't want to have to iterate through all of the available key-description pairs to find the key I'm looking for based on the value from the choice widget. Any suggestions? Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. Smiggins Hole 2010 - Unleash the Mongrel |
|
From: Kevin A. <al...@se...> - 2002-02-19 04:34:35
|
Has anyone experienced problems trying to figure out which .py file to run with any of the samples? Once you have more than a single Python script in a directory, knowing which one is the actual application and which files are just support modules becomes an issue. PythonCard programs always have at least two files, the main script such as minimal.py and a resource file like minimal.rsrc.py. The number of files increases as additional support modules, localized resource files, images, sounds, and other data files are added. Should we add standard sub-directory support to PythonCard to reduce clutter in the main application directory? The "clutter" increases once a script is compiled (.pyc) and/or optimized (.pyo) which is something that distutils does by default when it installs a package. Imagine the minimal sample directory containing: .cvsignore, minimal.fr.rsrc.py, minimal.fr.rsrc.pyc, minimal.fr.rsrc.pyo, minimal.py, minimal.pyc, minimal.pyo, minimal.rsrc.py, minimal.rsrc.pyc, minimal.rsrc.pyo, minimal.spec, readme.txt, setup.py, setup.pyc, setup.pyo It is likely that we will start splitting the samples off into their own zip for each release, partly to avoid the distutils auto-compiles. The suggestion has been made in the past that the resource files should be renamed so they don't have a .py extension (.rsrc), but there were arguments in favor of keeping the filenames unchanged as well. If the resource format migrates to XML then there shouldn't be any confusion over the extension, but that isn't going to happen soon. The next thing you need to know is that Python searches for modules and packages to import using sys.path. After running minimal.py with the -s (shell) command-line option on my machine, this is what sys.path returns. >>> import sys >>> sys.path ['.', 'C:\\python\\PythonCardPrototype\\samples\\minimal', 'c:\\python', 'C:\\Python21\\Pythonwin', 'C:\\Python21\\win32', 'C:\\Python21\\win32\\Lib', 'C:\\Python21', 'C:\\Python21\\DLLs', 'C:\\Python21\\lib', 'C:\\Python21\\lib\\plat-win', 'C:\\Python21\\lib\\lib-tk', 'C:\\Python21\\PIL', 'C:\\Python21\\PPM'] These are the directories and the order that Python checks for packages and modules when you use the import statement. Your local configuration will probably be similar but different. If we added a directory called 'modules' to a sample like resourceEditor and then added an empty __init__.py file to the 'modules' directory to make the directory a package then any additional Python code the application needed could be put in the 'modules' directory and imported since the current application directory is part of sys.path. As a test I created separate files for each of the dialog classes used by the resourceEditor: backgroundInfoDialog.py, stackInfoDialog.py, and menuDialog.py, and then moved the scripts and their resource files into the modules directory. I had to update the path each class used to load its resource file, but ignore that for now. I then updated the resourceEditor.py code to import the necessary classes. from modules.backgroundInfoDialog import BackgroundInfoDialog from modules.stackInfoDialog import StackInfoDialog from modules.menuDialog import MenuDialog One thing to note is that you don't want the name of the directory to conflict with any standard Python package or module name. While each PythonCard application could have its own directories, it might be easier to understand scripts written by different people if everyone used the same directory structure. When we were discussing localized resource files on the list, the suggestion was made to have a special directory that contains the localized resource files. I still think this is a good idea. I lean towards keeping the main .rsrc.py file and its associated module file in the same directory, but the issue is open for debate. Sounds, images, and data files could be placed in a one or more standard directories. We don't have to solve this problem now, but we should address it sometime if it is causing confusion, especially for programmers new to Python. If we don't provide standard directory support in the framework, one or more of the samples could show ways of using sub-directories to better organize more complex programs. Other suggestions or related issues? ka |
|
From: Kevin A. <al...@se...> - 2002-02-18 21:40:51
|
Yes I believe it is the IE edit control. If you want to write a platform-specific PythonCard program that is possible just as it is with wxPython. You can use ActiveX wrappers on Windows; see wxPython demo.py for an example. PythonCard tools like the Property Editor and resourceEditor won't know anything about the control, so you'll have to manually add the control say in the openBackground handler. This is typical of what you need to do when PythonCard doesn't support some feature yet that is already in wxPython. sizers, idle events, timers, etc. are handled this way in the samples. As we further develop the component model, it should be possible to add a component wrapper for specific or arbitrary ActiveX/COM components. I would prefer to concentrate on cross-platform components and issues right now, but anyone that wants to investigate further is welcome to do so and I'll help out with any questions they may have about the current framework. ka > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Jon > Edwards > Sent: Monday, February 18, 2002 1:19 PM > To: Kevin Altis; pythoncard-Users > Cc: nj...@an... > Subject: RE: [Pythoncard-users] FW: 75% WYSIWYG editor > > > From that screenshot, it looks like Radio uses the MS IE edit control > (perhaps embedded in the app)? Would this also be possible with Pythoncard > (embedding the edit control in the editing form) - though, obviously, only > on machines with IE installed? > > There's a good list of similar editors here - > http://www.bris.ac.uk/ISC/cms/ttw.html > > Sorry Nathan, but we tried structured-text with our (non-technical) users > and they just didn't "get" it. But they loved the wysiwyg editor (I used > this one http://vsbabu.org/webdev/zopedev/ieeditor.html) cos it > "Looks just > like Word"! I guess it depends on your target-user :-) > > Cheers, Jon > > Jon Edwards > Pricom Ltd > www.pricom.co.uk > > > This is off-topic for the PythonCard mailing list, except that I > > received an > > interesting message from a textRouter user who uses structured-text for > > writing HTML; textRouter is a PythonCard sample. This is not > > really WYSIWYG > > and I've included a screen shot of the Radio Userland 8 editor > in WYSIWYG > > mode to make it clear what I mean by WYSIWYG. > > > > However, I thought other people using textRouter and/or Zope or > providing > > HTML editing solutions to non-techies might be interested in > his comments. > > I've included his original email and a follow-up email and > cc'ed Nathan on > > this post in case you want to contact him directly. > > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > |
|
From: Jon E. <jo...@pc...> - 2002-02-18 21:18:22
|
From that screenshot, it looks like Radio uses the MS IE edit control (perhaps embedded in the app)? Would this also be possible with Pythoncard (embedding the edit control in the editing form) - though, obviously, only on machines with IE installed? There's a good list of similar editors here - http://www.bris.ac.uk/ISC/cms/ttw.html Sorry Nathan, but we tried structured-text with our (non-technical) users and they just didn't "get" it. But they loved the wysiwyg editor (I used this one http://vsbabu.org/webdev/zopedev/ieeditor.html) cos it "Looks just like Word"! I guess it depends on your target-user :-) Cheers, Jon Jon Edwards Pricom Ltd www.pricom.co.uk > This is off-topic for the PythonCard mailing list, except that I > received an > interesting message from a textRouter user who uses structured-text for > writing HTML; textRouter is a PythonCard sample. This is not > really WYSIWYG > and I've included a screen shot of the Radio Userland 8 editor in WYSIWYG > mode to make it clear what I mean by WYSIWYG. > > However, I thought other people using textRouter and/or Zope or providing > HTML editing solutions to non-techies might be interested in his comments. > I've included his original email and a follow-up email and cc'ed Nathan on > this post in case you want to contact him directly. |
|
From: Kevin A. <al...@se...> - 2002-02-18 20:51:17
|
Yesterday, on one of my blogs I made a post http://radio.weblogs.com/0102677/2002/02/17.html#a20 about WYSIWYG editors and CSS. There has been a raging debate on the "blog circuit" the last week or so about migration away from HTML tables and style tags in HTML to using CSS. In general, I agree with moving to CSS, but there are hurdles to overcome. Note that the wxHtmlWindow control has zero support for CSS and is unlikely to get CSS support in the near future. This is off-topic for the PythonCard mailing list, except that I received an interesting message from a textRouter user who uses structured-text for writing HTML; textRouter is a PythonCard sample. This is not really WYSIWYG and I've included a screen shot of the Radio Userland 8 editor in WYSIWYG mode to make it clear what I mean by WYSIWYG. However, I thought other people using textRouter and/or Zope or providing HTML editing solutions to non-techies might be interested in his comments. I've included his original email and a follow-up email and cc'ed Nathan on this post in case you want to contact him directly. ka -----Original Message----- From: Nathan Sain Sent: Sunday, February 17, 2002 9:38 PM To: al...@se... Subject: 75% WYSIWYG editor Kevin, I noticed a post of yours linked from scripting.com about WYSIWYG editors. I use the textRouter from the PythonCard samples and all my posts are WYSIWYG. I post to a system I wrote for Zope that uses the blogger API and can render structured-text into simple HTML. You can get lots more info on structured-text at Zope's website http://dev.zope.org/Members/jim/StructuredTextWiki/StructuredTextNGRules. Such a system could be used easily on client side python programs such as textRouter which would allow people to structure simple documents or posts in HTML. In fact much of Zope's documentation and an entire book The Zope Book is written in structured-text. While not being the exact solution to your question, I thought this could make a great improvement for simple text based clients like textRouter and HTML browsers that only support simple text area tag input. -- Kevin, I'm sorry, my previous message was confusing. My comment revolved around your statement: "This post doesn't even contain any formatting other than <P> tags and some special quoting now that I added that paragraph tag. But even this simple amount of HTML is more than most people know. If they just typed into a source editor and then posted their content and it wrapped all the words together on the web page they would be very confused" This problem in source editors can be solved by structured-text. Paragraphs receive the proper <p> tags, headings get <h1> tags, ordered and unordered lists get the proper <ol>,<ul>,<li> tags. Once posted CSS embedded into the template can provide styling for these tags. A source editor like textRouter is a nice thing to have because it is easy to implement as are textarea tags. It gives the user portability and styling. As stated in my previous message this not an answer to your question directly, it's more of a way to add value to existing source editors to make them more WYSIWYG. -- Nathan Sain Deer High School IT Dept. |
|
From: Patrick K. O'B. <po...@or...> - 2002-02-17 21:29:33
|
You'll probably have better luck posting this on the zodb-dev list. --- Patrick K. O'Brien Orbtech > -----Original Message----- > From: pyt...@li... > [mailto:pyt...@li...]On Behalf Of Magnus > Lie Hetland > Sent: Saturday, February 16, 2002 11:24 AM > To: pyt...@li... > Subject: [Pythoncard-users] ZODB problems... > > > I've been trying to install StandaloneZODB 1.0 (which I had hoped > would be easier than older versions), I keep getting a core dump when > I try to import it... Are there any known issues with gcc on Solaris > (Python 2.2)? > > -- > Magnus Lie Hetland The Anygui Project > http://hetland.org http://anygui.org > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users |
|
From: Kevin A. <al...@se...> - 2002-02-17 20:14:48
|
I've converted dialog.py so that there is a result dictionary of all the return values for a given standard dialog. I converted all the samples to use the new form, except textRouter, which I'll convert later this week. I left all of the old methods in place, so any code expecting the old form will still work. I want to remove that support once we finalize the way we want dialog calls to work. If you look at dialogs.py, you can see examples of user code calls to each standard dialog: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp e/samples/dialogs/ Here's an excerpt for the ColorDialog: def on_buttonColor_mouseClick(self, target, event): result = dialog.ColorDialog(self).result self.components.fldResults.text = "ColorDialog result:\naccepted: %s\nColor: %s" % (result['accepted'], result['color']) Pretty simple, but I'm not as happy with the result attribute as I thought I would be. The problem is that it doesn't work for the user-defined dialogs that use the GenericDialog class. The reason is that in order to use a modal dialog, the minimum steps are: initialize the dialog, call ShowModal, get the results, destroy the dialog. The only solution I can think of is to have a function call wrapper, so that calling a dialog and getting the results is just a single line function call. I went ahead and added a prototype of the color dialog as a function call to dialog.py to show how this might work instead of the current system. def colorDialog(parent): dialog = wx.wxColourDialog(parent) dialog.GetColourData().SetChooseFull(1) returned = dialog.ShowModal() if returned == wx.wxID_OK or returned == wx.wxID_YES: accepted = 1 else: accepted = 0 colorData = dialog.GetColourData() color = colorData.GetColour().Get() dialog.Destroy() return {'accepted':accepted, 'returned':returnedString(returned), 'color':color} From the shell it looks like: >>> from PythonCardPrototype import dialog >>> dialog.colorDialog(None) {'returned': 'Ok', 'accepted': 1, 'color': (255, 128, 64)} I think this approach will work for all the standard dialogs. I haven't done a function wrapper on a user-defined dialog yet, but it will work pretty much the same way. The actual class for the user-defined dialog will work basically the same way, but there will be a wrapper that hides the steps of init, show dialog, destroy. The standard dialog type that we don't currently support, but that might break this methodology is the wxWizard class, but since that is a "managed window" more than a normal dialog we can deal with that hurdle when we come to it. On a related note, I noticed while doing this code that returned values need to have a numeric or string constant that won't be changed by localization. Luckily, there is only one sample so far that uses 'returned' but I think it will be more widespread with user dialog. ka |
|
From: Magnus L. H. <ma...@he...> - 2002-02-16 17:24:06
|
I've been trying to install StandaloneZODB 1.0 (which I had hoped would be easier than older versions), I keep getting a core dump when I try to import it... Are there any known issues with gcc on Solaris (Python 2.2)? -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
|
From: Patrick K. O'B. <po...@or...> - 2002-02-16 02:21:26
|
I finished the conversion of the addresses sample to ZODB. It has been checked in to CVS under the sample directory as addressesZODB. For this to work, you will also need to check out the Bulldozer project, which can be found at http://sourceforge.net/projects/bdoz. I realize this is a lot to check out, but this is a prototype and I already had helper classes defined in my Bulldozer project. Anyhow, the example is pretty much just a quick attempt to get something working. I wouldn't hold it out as a shining example of anything in particular, other than a starting point for discussion. Also, the Find capability has been disabled until I figure out how I want to go about indexing data in the ZODB. Please take a look and see what you think. Feedback is welcome. Here are a couple of details that might not be immediately obvious: * The database will be created the first time you run the app, in the bdoz\apps\Addresser directory. * When the database is brand new, the app will create a new card and make that the current card. * Records are ordered by a key value, which is a random integer. So basically there is no visible order to the cards. (At least for now.) * If there are cards, the app will start with the first card. * Cards can be created with all blank values. (Not what you would want in a real app.) I'm sure there are other flaws. Enjoy. --- Patrick K. O'Brien Orbtech |
|
From: Kevin A. <al...@se...> - 2002-02-15 19:33:05
|
I forgot to mention that there is no particular reason why we couldn't just
use a result attribute (variable) instead of a method, so the code below
just becomes
self.result = {'accepted':self.accepted(),
'returned':self.returned()}
with no result() method. The user code call would look like:
>>> from PythonCardPrototype import dialog
>>> dialog.MessageDialog(None, 'a message', 'a title').result
{'accepted': 1, 'returned': 'Ok'}
ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, February 15, 2002 11:25 AM
> To: pythoncard-Users
> Cc: Robin Dunn
> Subject: [Pythoncard-users] possible single line dialog calls solution
>
>
> The basic problem looks like a generic issue of classes versus
> functions in
> Python. In order to make dialogs single line calls in user code I
> need to be
> able to instantiate the class and get a result in the same line
> of code. If
> we provided a function wrapper around a dialog class then the user could
> just call the function, but that makes subclassing problematic.
>
> Here's what we want to do more or less:
> >>> from PythonCardPrototype import dialog
> >>> dialog.MessageDialog(None, 'a message', 'a title').result()
> {'accepted': 1, 'returned': 'Ok'}
>
> Below is the code snippet from dialog.py that I'm working on. The
> ModalDialog class is already wrapping some basic dialog code. The
> only thing
> I've added is the _result variable and the result method. I can't just
> return a result at the end of the __init__ because __init__
> expects a return
> result of None.
>
> class MessageDialog( ModalDialog ) :
>
> def __init__( self, aParent, aMessage, aTitle,
> aIcon = ICON_INFORMATION, aButtons = BUTTON_OK |
> BUTTON_CANCEL) :
> ModalDialog.__init__( self, aParent )
> dialog = wx.wxMessageDialog(self._parent,
> aMessage,
> aTitle,
> aIcon | aButtons )
> self._setDialog( dialog )
> self._showModal()
> self._destroy()
> self._result = {'accepted':self.accepted(),
> 'returned':self.returned()}
>
> def result(self):
> return self._result
>
> I thought about trying something like:
>
> def __repr__(self):
> return str(result)
>
> The __repr__ trick works as long as all the return values are strings, but
> that is going to be tricky even for the basic dialogs such as font and
> color, though it is possible. It is going to be impossible for
> GenericDialog
> where the results could contain any arbitrary objects. Of course,
> the value
> returned as a string has to be converted back into a dictionary,
> so __repr__
> doesn't look like a good solution.
>
> There might be a clever way in Python of avoiding the result() method call
> tacked onto the end of the dialog instantiation, so I'm posting this note
> just in case the code wizards have a better idea. Otherwise, I'll do the
> conversion using the result() strategy. It still looks like typical Python
> usage, so it doesn't bother me and all dialog calls will work exactly the
> same way.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
|
|
From: Kevin A. <al...@se...> - 2002-02-15 19:23:06
|
The basic problem looks like a generic issue of classes versus functions in
Python. In order to make dialogs single line calls in user code I need to be
able to instantiate the class and get a result in the same line of code. If
we provided a function wrapper around a dialog class then the user could
just call the function, but that makes subclassing problematic.
Here's what we want to do more or less:
>>> from PythonCardPrototype import dialog
>>> dialog.MessageDialog(None, 'a message', 'a title').result()
{'accepted': 1, 'returned': 'Ok'}
Below is the code snippet from dialog.py that I'm working on. The
ModalDialog class is already wrapping some basic dialog code. The only thing
I've added is the _result variable and the result method. I can't just
return a result at the end of the __init__ because __init__ expects a return
result of None.
class MessageDialog( ModalDialog ) :
def __init__( self, aParent, aMessage, aTitle,
aIcon = ICON_INFORMATION, aButtons = BUTTON_OK |
BUTTON_CANCEL) :
ModalDialog.__init__( self, aParent )
dialog = wx.wxMessageDialog(self._parent,
aMessage,
aTitle,
aIcon | aButtons )
self._setDialog( dialog )
self._showModal()
self._destroy()
self._result = {'accepted':self.accepted(),
'returned':self.returned()}
def result(self):
return self._result
I thought about trying something like:
def __repr__(self):
return str(result)
The __repr__ trick works as long as all the return values are strings, but
that is going to be tricky even for the basic dialogs such as font and
color, though it is possible. It is going to be impossible for GenericDialog
where the results could contain any arbitrary objects. Of course, the value
returned as a string has to be converted back into a dictionary, so __repr__
doesn't look like a good solution.
There might be a clever way in Python of avoiding the result() method call
tacked onto the end of the dialog instantiation, so I'm posting this note
just in case the code wizards have a better idea. Otherwise, I'll do the
conversion using the result() strategy. It still looks like typical Python
usage, so it doesn't bother me and all dialog calls will work exactly the
same way.
ka
|
|
From: Kevin A. <al...@se...> - 2002-02-15 16:54:18
|
It isn't hard to do the code. What is hard is deciding on the way this will
be exposed. So far we haven't supported generic style overrides so that it
is possible to pass in the actual wxPython constants, instead we have always
wrapped the styles. Since are moving towards following wxPython more
closely, supporting the actual constants might make sense.
wxWindows/wxPython is filled with constants, but in order to manage the
complexity we have to be careful what is exposed and how we do it.
We could do something like this in choice.py (see code below KEA 2002-02-15
comments):
class ChoiceSpec(widget.WidgetSpec):
def __init__(self):
widget.WidgetSpec.__init__(self)
self.name = 'Choice'
self.parent = 'Widget'
self.parentName = self.parent
self.events.extend( [ event.SelectEvent ] )
self._attributes.update({
'items' : { 'presence' : 'optional', 'default' : [] },
'selected' : { 'presence' : 'optional', 'default' : None }
# KEA 2002-02-15
# added border attribute
'border' : { 'presence' : 'optional', 'default' : 'simple',
'values' : [ 'simple', 'double', 'sunken', 'raised', 'static' ] } })
self.attributes = self.parseAttributes(self._attributes)
self.requiredAttributes = self.parseRequiredAttributes()
self.optionalAttributes = self.parseOptionalAttributes()
class Choice(widget.Widget, wx.wxChoice):
"""
A popup menu.
"""
_spec = ChoiceSpec()
def __init__( self, aParent, aResource ) :
attributes = ['_items']
self._createAttributes(attributes)
widget.Widget.__init__( self, aParent, aResource )
# KEA 2002-02-15
# now we set the border
if aResource.border == 'simple':
border = wx.wxSIMPLE_BORDER
elif aResource.border == 'double':
# Windows only
border = wx.wxDOUBLE_BORDER
elif aResource.border == 'sunken':
border = wx.wxSUNKEN_BORDER
elif aResource.border == 'raised':
# GTK only
border = wx.wxRAISED_BORDER
elif aResource.border == 'static':
# Windows only
border = wx.wxSTATIC_BORDER
wx.wxChoice.__init__(
self,
aParent,
self.getId(),
wx.wxPoint( aResource.position[ 0 ], aResource.position[ 1 ] ),
wx.wxSize( aResource.size[ 0 ], aResource.size[ 1 ] ),
aResource.items,
style = wx.wxCLIP_SIBLINGS + border,
name = aResource.name
)
...
I didn't test it, but that probably works. Since wxControl inherits from
wxWindow and all of the components inherit from wxControl, this attribute
can probably be rolled higher up to Widget, but I'll have to look a little
closer at it since we already have a border style for some components. The
change above should allow you to manually change a .rsrc.py file to test the
border style for a Choice component, but it will be ignored by the Property
Editor window and resourceEditor.
We have tried to avoid the Windows and GTK specific settings in wxWindows
and discussed briefly on the list about a way to clearly identify which
options, styles, methods, etc. were platform-specific but never decided on
anything. I think the idea was to use some 'win', 'gtk', or 'mac' prefix so
it was obvious when something was platform-specific, which you can't tell
when you look at a wxWindows name, you have to check the docs.
Which style(s) in particular do you need?
ka
> From: rog...@gl...
> Sent: Friday, February 15, 2002 8:16 AM
> To: Kevin Altis
> Cc: pyt...@li...
> Subject: RE: [Pythoncard-users] border around choices
>
>
>
>
> At 15/02/2002 16:05:13, "Kevin Altis" <al...@se...> wrote:
> # > From: rog...@gl...
> # >
> # > I noticed from the resources editing tool kit that the choices
> # > component does
> # > not have a border property, and, looking at the wxWindows
> # > documentation it looks
> # > like it could be added in. How easy would this be to do?
> #
> # Do you mean these styles for wxWindow?
>
> Yes.
>
> # wxSIMPLE_BORDER Displays a thin border around the window.
> wxBORDER is the
> # old name for this style.
> # wxDOUBLE_BORDER Displays a double border. Windows only.
> # wxSUNKEN_BORDER Displays a sunken border.
> # wxRAISED_BORDER Displays a raised border. GTK only.
> # wxSTATIC_BORDER Displays a border suitable for a static
> control. Windows
> # only.
> # wxTRANSPARENT_WINDOW The window is transparent, that is, it will not
> # receive paint events. Windows only.
> #
> # If so, this is the kind of style option we'll have to add, there isn't
> # support right now. I don't see a special border attribute for wxChoice.
> #
> # As a side note, this reminds me that I always wanted to rename
> Choice to
> # PopupMenu, which seems like a better name.
>
> Agreed. Any idea when? I'm trying to replace the tools that we use with
> Pythoncard - and the apps that the old tools produce use the
> border style *a
> lot*.
>
> Roger
|
|
From: <rog...@gl...> - 2002-02-15 16:16:15
|
At 15/02/2002 16:05:13, "Kevin Altis" <al...@se...> wrote: # > From: rog...@gl... # > # > I noticed from the resources editing tool kit that the choices # > component does # > not have a border property, and, looking at the wxWindows # > documentation it looks # > like it could be added in. How easy would this be to do? # # Do you mean these styles for wxWindow? Yes. # wxSIMPLE_BORDER Displays a thin border around the window. wxBORDER is the # old name for this style. # wxDOUBLE_BORDER Displays a double border. Windows only. # wxSUNKEN_BORDER Displays a sunken border. # wxRAISED_BORDER Displays a raised border. GTK only. # wxSTATIC_BORDER Displays a border suitable for a static control. Windows # only. # wxTRANSPARENT_WINDOW The window is transparent, that is, it will not # receive paint events. Windows only. # # If so, this is the kind of style option we'll have to add, there isn't # support right now. I don't see a special border attribute for wxChoice. # # As a side note, this reminds me that I always wanted to rename Choice to # PopupMenu, which seems like a better name. Agreed. Any idea when? I'm trying to replace the tools that we use with Pythoncard - and the apps that the old tools produce use the border style *a lot*. Roger |
61 messages has been excluded from this view by a project administrator.
