Globals inaccesible with virtual ListCtrl?

Hi everyone,

In my OnGetItemText() function in a virtual ListCtrl, I try and access a global variable, and it has None assigned to it (by the statements at the top of the .py file, this startup code is not in a function). I print the global elsewhere (e.g. plunk a print in a menu handler) and it prints the current value. I print it in my virtual list control callback, and the global is None. I have a "global" declaration for said global in main() where it gets set, yet in the ListCtrl callback my globals are reverted to their initialization values.

Any thoughts appreciated,

Lee

P.S. The virtual ListCtrl is a subclassed xrc class, I just added a “subclass=MyNewClass” statement in the .xrc file–my first time around with such xrc subclasses.

···

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

Maybe you're accessing this variable by:
from mymodule import myglobal
This won't work -- "changing an imported variable locally doesn't change it in the module where it was imported from" - Mark Lutz.

Phil

···

At 11:10 AM 11/9/2006, you wrote:

Hi everyone,

    In my OnGetItemText() function in a virtual ListCtrl, I try and access a global variable, and it has None assigned to it (by the statements at the top of the .py file, this startup code is not in a function). I print the global elsewhere (e.g. plunk a print in a menu handler) and it prints the current value. I print it in my virtual list control callback, and the global is None. I have a "global" declaration for said global in main() where it gets set, yet in the ListCtrl callback my globals are reverted to their initialization values.

Any thoughts appreciated,
Lee

P.S. The virtual ListCtrl is a subclassed xrc class, I just added a "subclass=MyNewClass" statement in the .xrc file--my first time around with such xrc subclasses.

Thanks for the suggestion, so the ListCtrl code, apparently running in the ListCtrl module when it does the callback, has a different context globally than when code is running in my script. I kludged around it by calling a function in my overridden control that says “here is the global!”, passing it in a parameter that gets stashed away as a member. Fun, fun…

Lee

···

On Thu, 2006-11-09 at 11:42 -0800, Phil Mayes wrote:

At 11:10 AM 11/9/2006, you wrote:
>Hi everyone,
>
> In my OnGetItemText() function in a virtual ListCtrl, I try and
> access a global variable, and it has None assigned to it (by the
> statements at the top of the .py file, this startup code is not in a
> function). I print the global elsewhere (e.g. plunk a print in a menu
> handler) and it prints the current value.
..
Maybe you're accessing this variable by:
from mymodule import myglobal
This won't work -- "changing an imported variable locally doesn't change it
in the module where it was imported from" - Mark Lutz.

Phil

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

Well, now I’m in a pickle, if I call other objects that use globals, then they get the wrong values for the globals, and I would rather not 1) put special “globals” members in all my objects or 2) change the global context of the ListCtrl module.

So suggestions appreciated…

Lee

···

On Thu, 2006-11-09 at 14:55 -0500, Lee Merrill wrote:

Thanks for the suggestion, so the ListCtrl code, apparently running in the ListCtrl module when it does the callback, has a different context globally than when code is running in my script. I kludged around it by [passing required globals] in a parameter that gets stashed away as a member.

Lee



On Thu, 2006-11-09 at 11:42 -0800, Phil Mayes wrote:
At 11:10 AM 11/9/2006, you wrote:
>Hi everyone,
>
> In my OnGetItemText() function in a virtual ListCtrl, I try and
> access a global variable, and it has None assigned to it (by the
> statements at the top of the .py file, this startup code is not in a
> function). I print the global elsewhere (e.g. plunk a print in a menu
> handler) and it prints the current value...

Maybe you're accessing this variable by:
from mymodule import myglobal
This won't work -- "changing an imported variable locally doesn't change it
in the module where it was imported from" - Mark Lutz

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

global is just a namespace. In the context of module foo.py, it is the
module namespace of foo. In the context of module bar.py, it is the
module namespace of bar.

import foo
foo.hello = 1

Changes the module-level variable 'hello' of foo to 1. This is the same
thing that would happen if you had functions in foo...

def sethello():
    global hello
    hello = 1

def sethello2():
    globals()['hello'] = 1

Note that there does not exist a namespace that is truely global (in the
C sense) save the __builtins__ namespace, but you shouldn't muck about
with that because it contains things like: int, list, dict, type, etc.

If you have some sort of shared configuration information, you could
have a module called shared.py, which you use 'import shared' to get to,
and always use shared.attribute = ... .

- Josiah

···

Lee Merrill <Lee.Merrill@bustech.com> wrote:

Well, now I'm in a pickle, if I call other objects that use globals,
then *they* get the wrong values for the globals, and I would rather not
1) put special "globals" members in all my objects or 2) change the
global context of the ListCtrl module.

So suggestions appreciated...
Lee

On Thu, 2006-11-09 at 14:55 -0500, Lee Merrill wrote:

> Thanks for the suggestion, so the ListCtrl code, apparently running in
> the ListCtrl module when it does the callback, has a different context
> globally than when code is running in my script. I kludged around it
> by [passing required globals] in a parameter that gets stashed away as
> a member.
>
> Lee
>
> On Thu, 2006-11-09 at 11:42 -0800, Phil Mayes wrote:
>
> > At 11:10 AM 11/9/2006, you wrote:
> > >Hi everyone,
> > >
> > > In my OnGetItemText() function in a virtual ListCtrl, I try and
> > > access a global variable, and it has None assigned to it (by the
> > > statements at the top of the .py file, this startup code is not in a
> > > function). I print the global elsewhere (e.g. plunk a print in a menu
> > > handler) and it prints the current value...
> >
> > Maybe you're accessing this variable by:
> > from mymodule import myglobal
> > This won't work -- "changing an imported variable locally doesn't change it
> > in the module where it was imported from" - Mark Lutz

---
"There is nothing remarkable about it. All one has to do is press the
right keys at the right time and the computer programs itself." (ala
J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely
those of the author and do not necessarily represent those of the
company.

It works, thanks, now I have “import globModule” statements in each ListCtrl callback (this may well be inefficient? is there a way to tell if the module is already loaded?) and in my main script, and I now embark on search and replace on all my globals. Oh, but 'tis a mighty kludge! or at least an obscure one, in my opinion, and ordinary mortals will probably not consider this option.

What also wondering is how the ListCtrl module knew of my globals, but only with the values they had when the globals were first initialized…

Thanks for the help,

Lee

···

On Thu, 2006-11-09 at 13:26 -0800, Josiah Carlson wrote:

If you have some sort of shared configuration information, you could
have a module called shared.py, which you use 'import shared' to get to,
and always use shared.attribute = ... .

 - Josiah


Lee Merrill <Lee.Merrill@bustech.com> wrote:
> Well, now I'm in a pickle, if I call other objects that use globals,
> then *they* get the wrong values for the globals, and I would rather not
> 1) put special "globals" members in all my objects or 2) change the
> global context of the ListCtrl module.
>
> So suggestions appreciated...
> Lee
>
> On Thu, 2006-11-09 at 14:55 -0500, Lee Merrill wrote:
>
> > Thanks for the suggestion, so the ListCtrl code, apparently running in
> > the ListCtrl module when it does the callback, has a different context
> > globally than when code is running in my script. I kludged around it
> > by [passing required globals] in a parameter that gets stashed away as
> > a member.

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

“Curioser and curioser…”

If I write:

if not "globModule" in sys.modules: import "globModule"

I get a complaint that “globModule” is an uninitialized variable. If I put a counter in my ListCtrl’ish class, to only include “globModule” (say) 10000 times, and then stop, I see it work 4 times (my ListCtrl has 4 columns) and then a failure with “unitialized variable”, 4 more times it works, and another complaint, etc.

Only if I include “globModule” every time in the callback does it work…

Lee

···

On Thu, 2006-11-09 at 16:49 -0500, Lee Merrill wrote:

It works, thanks, now I have “import globModule” statements in each ListCtrl callback (this may well be inefficient? is there a way to tell if the module is already loaded?) and in my main script, and I now embark on search and replace on all my globals. Oh, but 'tis a mighty kludge! or at least an obscure one, in my opinion, and ordinary mortals will probably not consider this option.

What also wondering is how the ListCtrl module knew of my globals, but only with the values they had when the globals were first initialized...



Thanks for the help,

Lee



On Thu, 2006-11-09 at 13:26 -0800, Josiah Carlson wrote:
If you have some sort of shared configuration information, you could
have a module called shared.py, which you use 'import shared' to get to,
and always use shared.attribute = ... .

 - Josiah


Lee Merrill <Lee.Merrill@bustech.com> wrote:
> Well, now I'm in a pickle, if I call other objects that use globals,
> then *they* get the wrong values for the globals, and I would rather not
> 1) put special "globals" members in all my objects or 2) change the
> global context of the ListCtrl module.
>
> So suggestions appreciated...
> Lee
>
> On Thu, 2006-11-09 at 14:55 -0500, Lee Merrill wrote:
>
> > Thanks for the suggestion, so the ListCtrl code, apparently running in
> > the ListCtrl module when it does the callback, has a different context
> > globally than when code is running in my script. I kludged around it
> > by [passing required globals] in a parameter that gets stashed away as
> > a member.

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.


“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

It works, thanks, now I have "import globModule" statements in each
ListCtrl callback (this may well be inefficient? is there a way to tell
if the module is already loaded?) and in my main script, and I now
embark on search and replace on all my globals. Oh, but 'tis a mighty
kludge! or at least an obscure one, in my opinion, and ordinary mortals
will probably not consider this option.

Thanks to the sys.modules module cache, globModule will only be imported
once, and the import mechanism will "import" it almost instantly by
returning the cached module.

Also, sharing information via a module is not a kludge, it is a
legitimate use of a Python namespace. In a similar fashion, would
multiple modules importing os to gain access to os.path operations be a
kludge? Of course not, it's just a namespace that has some things that
may be useful to different portions of your program in different ways.

What also wondering is how the ListCtrl module knew of my globals, but
only with the values they had when the globals were first initialized...

Because 'from module import name' or 'import module' results in 'module'
only being imported once, and the 'name' will be pulled out at precisely
the time that 'from module import name' is executed. Toss in some print
statements to discover when portions of your module get executed, that
will help you understand a bit more.

- Josiah

···

Lee Merrill <Lee.Merrill@bustech.com> wrote:

On Thu, 2006-11-09 at 13:26 -0800, Josiah Carlson wrote:
> If you have some sort of shared configuration information, you could
> have a module called shared.py, which you use 'import shared' to get to,
> and always use shared.attribute = ... .
>
> - Josiah
>
>
> Lee Merrill <Lee.Merrill@bustech.com> wrote:
> > Well, now I'm in a pickle, if I call other objects that use globals,
> > then *they* get the wrong values for the globals, and I would rather not
> > 1) put special "globals" members in all my objects or 2) change the
> > global context of the ListCtrl module.
> >
> > So suggestions appreciated...
> > Lee
> >
> > On Thu, 2006-11-09 at 14:55 -0500, Lee Merrill wrote:
> >
> > > Thanks for the suggestion, so the ListCtrl code, apparently running in
> > > the ListCtrl module when it does the callback, has a different context
> > > globally than when code is running in my script. I kludged around it
> > > by [passing required globals] in a parameter that gets stashed away as
> > > a member.

---
"There is nothing remarkable about it. All one has to do is press the
right keys at the right time and the computer programs itself." (ala
J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely
those of the author and do not necessarily represent those of the
company.

"Curioser and curioser..."

If I write:

    if not "globModule" in sys.modules: import "globModule"

I get a complaint that "globModule" is an uninitialized variable. If I
put a counter in my ListCtrl'ish class, to only include
"globModule" (say) 10000 times, and then stop, I see it work 4 times (my
ListCtrl has 4 columns) and then a failure with "unitialized variable",
4 more times it works, and another complaint, etc.

I presume you meant...

if not "globModule" in sys.modules: import globModule

The reason it doesn't work has to do with the Python compiler. Unless
you declare something as global, like...

def foo():
    global globModule
    #this actually won't also work...
    if not "globModule" in sys.modules:
        import globModule
    ...

Then Python's compiler believes that the _name_ 'globModule' is a local,
and because you didn't assign to that name in the particular namespace
(of foo, or whatever), it will tell you that you tried to use a variable
without assigning to it.

What I would do is to just put 'import globModule' at the top of every
module that needs globModule access, and call it good. I can guarantee
that it will be faster (to type and run) than trying to muck about with
'global', "globModule" in sys.modules, etc.

- Josiah

···

Lee Merrill <Lee.Merrill@bustech.com> wrote:

Only if I include "globModule" every time in the callback does it
work...

Lee

On Thu, 2006-11-09 at 16:49 -0500, Lee Merrill wrote:

> It works, thanks, now I have "import globModule" statements in each
> ListCtrl callback (this may well be inefficient? is there a way to
> tell if the module is already loaded?) and in my main script, and I
> now embark on search and replace on all my globals. Oh, but 'tis a
> mighty kludge! or at least an obscure one, in my opinion, and ordinary
> mortals will probably not consider this option.
>
> What also wondering is how the ListCtrl module knew of my globals, but
> only with the values they had when the globals were first
> initialized...
>
> Thanks for the help,
> Lee
>
> On Thu, 2006-11-09 at 13:26 -0800, Josiah Carlson wrote:
>
>
>
> >
> >
> > If you have some sort of shared configuration information, you could
> > have a module called shared.py, which you use 'import shared' to get to,
> > and always use shared.attribute = ... .
> >
> > - Josiah
> >
> >
> > Lee Merrill <Lee.Merrill@bustech.com> wrote:
> > > Well, now I'm in a pickle, if I call other objects that use globals,
> > > then *they* get the wrong values for the globals, and I would rather not
> > > 1) put special "globals" members in all my objects or 2) change the
> > > global context of the ListCtrl module.
> > >
> > > So suggestions appreciated...
> > > Lee
> > >
> > > On Thu, 2006-11-09 at 14:55 -0500, Lee Merrill wrote:
> > >
> > > > Thanks for the suggestion, so the ListCtrl code, apparently running in
> > > > the ListCtrl module when it does the callback, has a different context
> > > > globally than when code is running in my script. I kludged around it
> > > > by [passing required globals] in a parameter that gets stashed away as
> > > > a member.
>
>
>
> ---
> "There is nothing remarkable about it. All one has to do is press the
> right keys at the right time and the computer programs itself." (ala
> J.S. Bach)
>
> Unless otherwise stated, any views presented in this e-mail are solely
> those of the author and do not necessarily represent those of the
> company.

---
"There is nothing remarkable about it. All one has to do is press the
right keys at the right time and the computer programs itself." (ala
J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely
those of the author and do not necessarily represent those of the
company.

Thanks for your reply (replies!) Josiah, it’s good to know that the cache will prevent importing multiple times. But I can’t put an import in the ListCtrl module, so I think there is a substantial problem here with the virtual ListCtrl callbacks, they need somehow to have the user’s current global context when the callbacks are made, would be my guess.

Now I’m wondering (if the cache prevents another import) how doing an import in each ListCtrl callback means I see the current global variable values. It would seem to do some work here, to refresh the values of the global variables? For I always see their current values when I do this, yet if I don’t do this, I only see the values assigned at initialization.

Thanks again,

Lee

> It works, thanks, now I have "import globModule" statements in each
> ListCtrl callback (this may well be inefficient? is there a way to tell
> if the module is already loaded?) and in my main script, and I now
> embark on search and replace on all my globals. Oh, but 'tis a mighty
> kludge! or at least an obscure one, in my opinion, and ordinary mortals
> will probably not consider this option.

Thanks to the sys.modules module cache, globModule will only be imported
once, and the import mechanism will "import" it almost instantly by
returning the cached module.

···

On Thu, 2006-11-09 at 14:36 -0800, Josiah Carlson wrote:

Lee Merrill Lee.Merrill@bustech.com wrote:

> What also wondering is how the ListCtrl module knew of my globals, but
> only with the values they had when the globals were first initialized...

Because 'from module import name' or 'import module' results in 'module'
only being imported once, and the 'name' will be pulled out at precisely
the time that 'from module import name' is executed. Toss in some print
statements to discover when portions of your module get executed, that
will help you understand a bit more.


 - Josiah

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

Thanks for your reply (replies!) Josiah, it's good to know that the
cache will prevent importing multiple times. But I can't put an import
in the ListCtrl module, so I think there is a substantial problem here
with the virtual ListCtrl callbacks, they need somehow to have the
user's current global context when the callbacks are made, would be my
guess.

Why can't you import the 'globModule' in the module level namespace of
another module? Is it something with the way your software is designed?
I can't believe that there is some usage that is somehow breaking with
your imports that hasn't been solved before.

Now I'm wondering (if the cache prevents another import) how doing an
import in each ListCtrl callback means I see the current global variable
values. It would seem to do some work here, to refresh the values of the
global variables? For I always see their current values when I do this,
yet if I don't do this, I only see the values assigned at
initialization.

I don't understand what you are trying to say. Show some code with some
context (example names of modules with short example content), and I
will do my best to explain why you are getting the results you are, and
how you can get what you want.

- Josiah

···

Lee Merrill <Lee.Merrill@bustech.com> wrote:

On Thu, 2006-11-09 at 14:36 -0800, Josiah Carlson wrote:

> Lee Merrill <Lee.Merrill@bustech.com> wrote:
> > It works, thanks, now I have "import globModule" statements in each
> > ListCtrl callback (this may well be inefficient? is there a way to tell
> > if the module is already loaded?) and in my main script, and I now
> > embark on search and replace on all my globals. Oh, but 'tis a mighty
> > kludge! or at least an obscure one, in my opinion, and ordinary mortals
> > will probably not consider this option.
>
> Thanks to the sys.modules module cache, globModule will only be imported
> once, and the import mechanism will "import" it almost instantly by
> returning the cached module.
>

...

>
>
> > What also wondering is how the ListCtrl module knew of my globals, but
> > only with the values they had when the globals were first initialized...
>
> Because 'from module import name' or 'import module' results in 'module'
> only being imported once, and the 'name' will be pulled out at precisely
> the time that 'from module import name' is executed. Toss in some print
> statements to discover when portions of your module get executed, that
> will help you understand a bit more.
>
>
> - Josiah
>

---
"There is nothing remarkable about it. All one has to do is press the
right keys at the right time and the computer programs itself." (ala
J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely
those of the author and do not necessarily represent those of the
company.

Hi Josiah,

Here is a sample of code that illustrates the problem I have encountered. If you click the "Increment Avar" button, the global value is incremented, however, whenever the ListCtrl is scrolled, the value "Avar = 1" is always printed. Now I can get around this as you mentioned by putting Avar in a global .py file and then importing this .py file in the OnGetItemText callback, and using globModule.Avar everywhere, but this I think people would not generally guess to do!

Thanks for considering all this,

Lee

=== lc.xrc ===

<?xml version="1.0" encoding="iso8859-1"?>
<title></title>

<object class="wxBoxSizer">

  <orient>wxVERTICAL</orient>

  <object class="sizeritem">

    <object class="wxListCtrl" name="LIST_CTRL" subclass="lc.TraceListCtrl">

      <style>wxLC_REPORT|wxLC_VIRTUAL|wxLC_HRULES|wxLC_VRULES</style>

    </object>

    <option>1</option>

    <flag>wxEXPAND</flag>

  </object>

  <object class="sizeritem">

    <object class="wxButton" name="INC_AVAR">

      <label>Increment Avar</label>

    </object>

    <flag>wxALL</flag>

    <border>10</border>

  </object>

</object>

=== lc.py ===

#!/usr/bin/python

import os, platform, sys import wx, wx.xrc Avar = 1

def getCtrl(ctrlName, parent=None): if not parent: parent = Root

return wx.xrc.XRCCTRL(parent, ctrlName)

class TraceListCtrl(wx.ListCtrl):

def __init__(self):         self.PostCreate(wx.PreListCtrl())         self.Bind(wx.EVT_WINDOW_CREATE, self.OnCreate)      def OnCreate(self, evt):         self.attr = wx.ListItemAttr()          self.InsertColumn(0, "Col 1")

    self.InsertColumn(1, "Col 2")

    self.InsertColumn(2, "Col 3")

    self.InsertColumn(3, "Col 4")

    for col in xrange(4):

        self.SetColumnWidth(col, wx.LIST_AUTOSIZE)

    self.Unbind(wx.EVT_WINDOW_CREATE)

def OnGetItemText(self, row, col):

    if col == 0:

        return str(row+1)

    print "In OnGetItemText: Avar is %d" % Avar

    return "(%d - %d)" % (row+1, col+1)

def OnGetItemAttr(self, row):

    return self.attr

class App(wx.App):

def __init__(self, redirect=True, fileName=None):

    wx.App.__init__(self, redirect, fileName)

def OnInit(self):

    global Root

    self.xrc = wx.xrc.XmlResource("lc.xrc")

    Root = self.frame = self.xrc.LoadFrame(None, "MAIN_FRAME")

    szr = Root.GetSizer()

    szr.Fit(Root)

    Root.Bind(wx.EVT_BUTTON, self.onButton)

    return True

def onButton(self, evt):

    global Avar

    Avar += 1

    print "In onButton: Avar is %d" % Avar

def main():

myApp = App(False)

lc = getCtrl("LIST_CTRL")

lc.SetItemCount(100)

Root.SetSize( (400, 300) )

Root.Show()

Avar = 2

myApp.MainLoop()

if name == “main”:

sys.exit(main())
···

On Fri, 2006-11-10 at 08:10 -0800, Josiah Carlson wrote:

I don't understand what you are trying to say. Show some code with some
context (example names of modules with short example content), and I
will do my best to explain why you are getting the results you are, and
how you can get what you want.

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

[snip]

def main():
    myApp = App(False)
    lc = getCtrl("LIST_CTRL")
    lc.SetItemCount(100)
    Root.SetSize( (400, 300) )
    Root.Show()
    Avar = 2

There is no global declaration, so Avar is not updated in the module
level scope.

    myApp.MainLoop()

I'm still looking...

- Josiah

···

Lee Merrill <Lee.Merrill@bustech.com> wrote:

There is no global declaration, so Avar is not updated…

Yes, it would probably be best to just remove the “Avar = 2” statement, it’s not really necessary as part of the demonstration.

I’m still looking…

Thanks!

Lee

···

On Fri, 2006-11-10 at 09:51 -0800, Josiah Carlson wrote:

Lee Merrill <Lee.Merrill@bustech.com> wrote:
[snip]
> def main():
> myApp = App(False)
> lc = getCtrl("LIST_CTRL")
> lc.SetItemCount(100)
> Root.SetSize( (400, 300) )
> Root.Show()
> Avar = 2

There is no global declaration, so Avar is not updated in the module
level scope.

> myApp.MainLoop()

I'm still looking...

 - Josiah

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

According to my testing on wxPython 2.7 (I can't get it to work using
2.6), the XRC loading doesn't understand the wxLC_VIRTUAL style. More
specifically, it's not producing a complete virtual control, or at least
not one that can use overridden methods. If it were, then I would be
getting text displayed in the completely unchanged version that I am
using, but I'm not. The list, though having 100 rows and 5 columns, is
completely empty.

This is beyond me, but from what I understand, it's not a matter of
variable access, it's a matter of XRC + virtual list controls being
broken.

- Josiah

···

Lee Merrill <Lee.Merrill@bustech.com> wrote:

> There is no global declaration, so Avar is not updated...

Yes, it would probably be best to just remove the "Avar = 2" statement,
it's not really necessary as part of the demonstration.

> I'm still looking...

Thanks!

Lee

On Fri, 2006-11-10 at 09:51 -0800, Josiah Carlson wrote:

> Lee Merrill <Lee.Merrill@bustech.com> wrote:
> [snip]
> > def main():
> > myApp = App(False)
> > lc = getCtrl("LIST_CTRL")
> > lc.SetItemCount(100)
> > Root.SetSize( (400, 300) )
> > Root.Show()
> > Avar = 2
>
> There is no global declaration, so Avar is not updated in the module
> level scope.
>
> > myApp.MainLoop()
>
> I'm still looking...
>
> - Josiah
>

---
"There is nothing remarkable about it. All one has to do is press the
right keys at the right time and the computer programs itself." (ala
J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely
those of the author and do not necessarily represent those of the
company.

Hi Josiah,

Sorry, I should have mentioned I'm using wxPython 2.6, and the list shows the text for that version in my setup. But maybe the problem I'm seeing is another symptom of this xrc/virtual ListCtrl problem, which just has different characteristics in 2.7. I really think I should punt here, alas, because after moving lots of global variables into a glob.py file, my code is really cluttered, and I had to remove all the globals declarations, so if I forget and don't put the glob. prefix on a global when I should, then I'm going to get some obscure bugs if I assign to a global.

The critical part for me is that in 2.6 it doesn't break completely, it works well enough so that I don't realize there is a problem with global variables having different values depending on where they are accessed...

Thanks for looking into this,

Lee

···

On Fri, 2006-11-10 at 10:38 -0800, Josiah Carlson wrote:

According to my testing on wxPython 2.7 (I can't get it to work using
2.6), the XRC loading doesn't understand the wxLC_VIRTUAL style. More
specifically, it's not producing a complete virtual control, or at least
not one that can use overridden methods. If it were, then I would be
getting text displayed in the completely unchanged version that I am
using, but I'm not. The list, though having 100 rows and 5 columns, is
completely empty.

This is beyond me, but from what I understand, it's not a matter of
variable access, it's a matter of XRC + virtual list controls being
broken.

 - Josiah

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

Hi Josiah,

    Sorry, I should have mentioned I'm using wxPython 2.6, and the list
shows the text for that version in my setup. But maybe the problem I'm
seeing is another symptom of this xrc/virtual ListCtrl problem, which
just has different characteristics in 2.7. I really think I should punt
here, alas, because after moving lots of global variables into a glob.py
file, my code is really cluttered, and I had to remove all the globals
declarations, so if I forget and don't put the glob. prefix on a global
when I should, then I'm going to get some obscure bugs if I assign to a
global.

Wouldn't a quick grep for 'global' give you all of the instances you
needed to change? Also, replacing your use of 'global' with a module
in which all of your state information is kept seems to me to be an
_improvement_ in clutter, nevermind variable updating, which is not
possible with things like:
    from globalVariables import name

If you are experiencing clutter, are you sure it's not just because you
have longer names now 'globModule.name' vs. 'name'? You can always
change that to 'gM.name' which would be far more concise, and doable on
a per module basis with:
    import globModule as gM

    The critical part for me is that in 2.6 it doesn't break completely,
it works well enough so that I don't realize there is a problem with
global variables having different values depending on where they are
accessed...

If you are getting different values depending on where you are accessing,
then you aren't accessing or updating them the same way.

If you have some namespace, say 'globalVariables' that you imported via
'import globalVariables', then as long as you _always_ access it via
'globalVariables.variable_name', it will work. How do I know? Because
if it didn't work, then no imports would work.

Keep it simple, keep it consistant.

- Josiah

···

Lee Merrill <Lee.Merrill@bustech.com> wrote:

Thanks for looking into this,
Lee

On Fri, 2006-11-10 at 10:38 -0800, Josiah Carlson wrote:

> According to my testing on wxPython 2.7 (I can't get it to work using
> 2.6), the XRC loading doesn't understand the wxLC_VIRTUAL style. More
> specifically, it's not producing a complete virtual control, or at least
> not one that can use overridden methods. If it were, then I would be
> getting text displayed in the completely unchanged version that I am
> using, but I'm not. The list, though having 100 rows and 5 columns, is
> completely empty.
>
> This is beyond me, but from what I understand, it's not a matter of
> variable access, it's a matter of XRC + virtual list controls being
> broken.
>
> - Josiah

---
"There is nothing remarkable about it. All one has to do is press the
right keys at the right time and the computer programs itself." (ala
J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely
those of the author and do not necessarily represent those of the
company.

Just for the record, the problem seems to be in XRC in 2.6 too, when I make a subclass of ListCtrl by hand instead of doing XRC subclassing, it works, globals accessed in the MyListCtrl callback have the current value instead of their first-initialized value.

So the moral of the story would be to not use subclassing in XRC for now?

Lee

···

On Fri, 2006-11-10 at 10:38 -0800, Josiah Carlson wrote:

According to my testing on wxPython 2.7 (I can't get it to work using
2.6), the XRC loading doesn't understand the wxLC_VIRTUAL style. More
specifically, it's not producing a complete virtual control, or at least
not one that can use overridden methods...

“There is nothing remarkable about it. All one has to do is press the right keys at the right time and the computer programs itself.” (ala J.S. Bach)

Unless otherwise stated, any views presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

Lee Merrill wrote:

Just for the record, the problem seems to be in XRC in 2.6 too, when I make a subclass of ListCtrl by hand instead of doing XRC subclassing, it works, globals accessed in the MyListCtrl callback have the current value instead of their first-initialized value.

So the moral of the story would be to not use subclassing in XRC for now?

There is nothing in how the XRC subclassing is done that should have any effect on any Python code's ability to access its module namespace. Please provide a small sample that shows the problem so we can see exactly what you are tying to do and how it is going wrong.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!