the index of the STC
that your pop-up came
from <= there was no
GetItemIndex in
FlexSizer. so I doubt I
can get the index of the
selected control. and I
have used
event.GetEventObject()
to get current stc
object. but there is
still statictext
control. so I am trying
continuously.
get
the editor and static
text pair for that index
remove
them from the lists,
self.texts and
self.editor
delete
them
Python list? I think a dictionary
might be better/easier for this.
See attached.
Werner
–
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit [http://groups.google.com/group/wxPython-users?hl=en](http://groups.google.com/group/wxPython-users?hl=en)
It works well. thank you for your advice all.
(Gadget/Steve, werner, Robin Dunn, Tobias
Weber, CM, Andrea Gavana, Steven Sproat, Tim
Roberts, grunculus)
Wonjun, Choi
hello.
I have a problem.
when I add pythonSTC or fortranSTC to sizer, the
folding button is not working. Does anyone know the
reason?
I am sorry. I forgot an event function.
self.Bind(stc.EVT_STC_UPDATEUI, self.onUpdateUI)
self.Bind(stc.EVT_STC_MARGINCLICK, self.onMarginClick)
self.Bind(wx.EVT_KEY_DOWN, self.onKeyPressed)
when I inserted the controls by below method, the controls
or visit [http://groups.google.com/group/wxPython-users?hl=en](http://groups.google.com/group/wxPython-users?hl=en)
Because both were inserted at position 1, so the 'first' becomes the
second and assuming that you are still following the previous
pattern, two cols, you need to insert the first at position 2 and
the second at position 3.
actually I don’t understand sizer’s index pattern.
as you said. the index was (0, 1), (2, 3), (4, 5)…
and can I get the index of the selected stc? it seems like there is no function to get the index of the control in Sizer.
actually I don't understand sizer's index pattern.
as you said. the index was (0, 1), (2, 3), (4, 5)...
and can I get the index of the selected stc? it seems like there is no
function to get the index of the control in Sizer.
> actually I don't understand sizer's index pattern.
> as you said. the index was (0, 1), (2, 3), (4, 5)...
> and can I get the index of the selected stc? it seems
like there is no
> function to get the index of the control in Sizer.
>
index = sizer.GetItemIndex(widget)
--
Robin Dunn
Software Craftsman
[http://wxPython.org](http://wxPython.org)
--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit [http://groups.google.com/group/wxPython-users?hl=en](http://groups.google.com/group/wxPython-users?hl=en)
it seems like there is no GetItemIndex function in FlexSizer or
wx.Sizer.
there is. It is the part of the _core sizer:
def Sizer.GetItemIndex(self, item)
Returns: int
Returns the index of the given *item* within the sizer. Does not
search recursivly. The item parameter can be either a window or a
sizer. An assertion is raised if the item is not found in the sizer
> actually I don't understand sizer's index pattern.
> as you said. the index was (0, 1), (2, 3), (4, 5)...
> and can I get the index of the selected stc? it seems
like there is no
> function to get the index of the control in Sizer.
>
index = sizer.GetItemIndex(widget)
--
Robin Dunn
Software Craftsman
[http://wxPython.org](http://wxPython.org)
--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit [http://groups.google.com/group/wxPython-users?hl=en](http://groups.google.com/group/wxPython-users?hl=en)
it seems like there is no GetItemIndex function in FlexSizer or
wx.Sizer.
there is. It is the part of the _core sizer:
def Sizer.GetItemIndex(self, item)
Returns: int
Returns the index of the given *item* within the sizer. Does not
search recursivly. The item parameter can be either a window or a
sizer. An assertion is raised if the item is not found in the sizer
it seems like there is no GetItemIndex function in FlexSizer or wx.Sizer.
There is in 2.9, but not in 2.8, although writing your own is not particularly complicated.
I am impressed how you managed to stretch this thread to 100+ messages on an issue like this. I wonder what will happen when you really hit the difficult stuff.
it seems like there is no GetItemIndex function in FlexSizer or wx.Sizer.
There is in 2.9, but not in 2.8, although writing your own is not particularly complicated.
I am impressed how you managed to stretch this thread to 100+ messages on an issue like this. I wonder what will happen when you really hit the difficult stuff.
it seems like there is no GetItemIndex function in FlexSizer or wx.Sizer.
There is in 2.9, but not in 2.8, although writing your own is not particularly complicated.
I am impressed how you managed to stretch this thread to 100+ messages on an issue like this. I wonder what will happen when you really hit the difficult stuff.
it seems like there is no GetItemIndex function in FlexSizer or wx.Sizer.
There is in 2.9, but not in 2.8, although writing your own is not particularly complicated.
I am impressed how you managed to stretch this thread to 100+ messages on an issue like this. I wonder what will happen when you really hit the difficult stuff.
Sorry, there is no one who knows about this. so I posted more than 100 messages.
I didn’t install 2.9 version because it is not stable yet. so when it is stable, I will install it.
It is perfectly “stable”, I use it all the time in production code (although I’d kill the guy who suggested the modifications to the way sizers are handled ). Here “stable” does not mean what you think you mean:
--
Robin Dunn
Software Craftsman
[http://wxPython.org](http://wxPython.org)
--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit [http://groups.google.com/group/wxPython-users?hl=en](http://groups.google.com/group/wxPython-users?hl=en)
it seems like there is no GetItemIndex
function in FlexSizer or wx.Sizer.
There is in 2.9, but not in 2.8, although
writing your own is not particularly complicated.
I am impressed how you managed to stretch this
thread to 100+ messages on an issue like this. I
wonder what will happen when you really hit the
difficult stuff.
Andrea.
"Imagination Is The Only Weapon In The War Against
--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit [http://groups.google.com/group/wxPython-users?hl=en](http://groups.google.com/group/wxPython-users?hl=en)
Sorry, there is no one who knows about this. so I posted more
than 100 messages.
I didn't install 2.9 version because it is not stable yet. so when
it is stable, I will install it.
Totally stable for me- Be aware that switching back and forth in a
wxPython verison is easy - so I do not see
I didn't install 2.9 version because it is not stable yet. so
when it is stable, I will install it.
wonjunchoi, it might be good that you start a new thread at some
point. Because your original question of this thread has been
answered a long time ago.
I am trying to follow your problem, but the way you keep giving a
little information here and there is making this pretty difficult
and time consuming. Maybe it is time again for a little sample
application with a detailed description of what you can’t make to
work.
It is perfectly "stable", I use it all the time in
production code (although I’d kill the guy who suggested the
modifications to the way sizers are handled ).
You mean the change in how the spare space is distributed?
Here “stable” does not mean what you think you mean:
A self-serving bias occurs when people attribute their successes to internal or personal factors but attribute their failures to situational factors beyond their control. The self-serving bias can be seen in the common human tendency to take credit for success but to deny responsibility for failure.[1]
Here is the implementation of the method. I expect that it will work in
2.8 as well, but I have not tested it:
def GetItemIndex(self, item):
"""
Returns the index of the given *item* within the sizer. Does not
search recursively. The *item* parameter can be either a window
or a sizer. An assertion is raised if the item is not found in
the sizer.
"""
sItem = self.GetItem(item)
assert sItem is not None, "Item not found in the sizer."
allItems = self.Children
idx = 0
for i in allItems:
if i.this == sItem.this:
break
idx += 1
return idx
I didn't install 2.9 version because it is not stable yet. so
when it is stable, I will install it.
wonjunchoi, it might be good that you start a new thread at some
point. Because your original question of this thread has been
answered a long time ago.
I am trying to follow your problem, but the way you keep giving a
little information here and there is making this pretty difficult
and time consuming. Maybe it is time again for a little sample
application with a detailed description of what you can’t make to
work.
It is perfectly "stable", I use it all the time in
production code (although I’d kill the guy who suggested the
modifications to the way sizers are handled ).
You mean the change in how the spare space is distributed?
Correct, I had huge headaches trying to figure out how to maintain 2 custom controls I have written supporting both 2.8 and 2.9. Not to mention the self.GetEventHandler().ProcessEvent() vs. self.ProcessWindowEvent() issue, which I pray will not wreak too much havoc to AGW, or I’ll have to go through the whole library and apply conditional switches all over the place to support 2.8 and 2.9 at the same time.
Here “stable” does not mean what you think you mean:
IIRC, he is on Linux and 2.9 doesn't work that great on there - at
least for me.
This I don’t know, I don’t use Linux, but you should make sure Robin and the wxWidgets devs are aware of the issues (if you haven’t already done it, I mean).
self.GetEventHandler().ProcessEvent() should be the same as self.ProcessWindowEvent(), and the former should still be doable in 2.9, is that not the case? The thing that was changed is that it is no longer allowed to call self.ProcessEvent when self is a window class, because that bypasses any pushed event handlers or validators on the window.
One other related change that comes to mind is that in 2.9 you need to pop any pushed event handlers before the window is destroyed as they will no longer take ownership of those event handler objects.
···
On 10/25/11 12:39 PM, Andrea Gavana wrote:
Correct, I had huge headaches trying to figure out how to maintain 2
custom controls I have written supporting both 2.8 and 2.9. Not to
mention the self.GetEventHandler().ProcessEvent() vs.
self.ProcessWindowEvent() issue, which I pray will not wreak too much
havoc to AGW, or I'll have to go through the whole library and apply
conditional switches all over the place to support 2.8 and 2.9 at the
same time.
Correct, I had huge headaches trying to figure out how to maintain 2
custom controls I have written supporting both 2.8 and 2.9. Not to
mention the self.GetEventHandler().ProcessEvent() vs.
self.ProcessWindowEvent() issue, which I pray will not wreak too much
havoc to AGW, or I’ll have to go through the whole library and apply
conditional switches all over the place to support 2.8 and 2.9 at the
same time.
self.GetEventHandler().ProcessEvent() should be the same as self.ProcessWindowEvent(), and the former should still be doable in 2.9, is that not the case? The thing that was changed is that it is no longer allowed to call self.ProcessEvent when self is a window class, because that bypasses any pushed event handlers or validators on the window.
One other related change that comes to mind is that in 2.9 you need to pop any pushed event handlers before the window is destroyed as they will no longer take ownership of those event handler objects.
Correct, I had huge headaches trying to figure out how to maintain 2
custom controls I have written supporting both 2.8 and 2.9. Not to
mention the self.GetEventHandler().ProcessEvent() vs.
self.ProcessWindowEvent() issue, which I pray will not wreak too much
havoc to AGW, or I’ll have to go through the whole library and apply
conditional switches all over the place to support 2.8 and 2.9 at the
same time.
self.GetEventHandler().ProcessEvent() should be the same as self.ProcessWindowEvent(), and the former should still be doable in 2.9, is that not the case? The thing that was changed is that it is no longer allowed to call self.ProcessEvent when self is a window class, because that bypasses any pushed event handlers or validators on the window.
One other related change that comes to mind is that in 2.9 you need to pop any pushed event handlers before the window is destroyed as they will no longer take ownership of those event handler objects.
Correct, I had huge headaches trying to figure out how to maintain 2
custom controls I have written supporting both 2.8 and 2.9. Not to
mention the self.GetEventHandler().ProcessEvent() vs.
self.ProcessWindowEvent() issue, which I pray will not wreak too much
havoc to AGW, or I’ll have to go through the whole library and apply
conditional switches all over the place to support 2.8 and 2.9 at the
same time.
self.GetEventHandler().ProcessEvent() should be the same as self.ProcessWindowEvent(), and the former should still be doable in 2.9, is that not the case? The thing that was changed is that it is no longer allowed to call self.ProcessEvent when self is a window class, because that bypasses any pushed event handlers or validators on the window.
One other related change that comes to mind is that in 2.9 you need to pop any pushed event handlers before the window is destroyed as they will no longer take ownership of those event handler objects.
where can I fine the document for the method GetItemIndex
I couldn’t find any document for this.
>I didn't install 2.9 version because it is not stable yet. so
when it is stable, I will install it.
>wonjunchoi, it might be good that you start a new thread at some
point. Because your original question of this thread has been
answered a >long time ago.
>I am trying to follow your problem, but the way you keep giving a
little information here and there is making this pretty difficult
and time >consuming. Maybe it is time again for a little sample
application with a detailed description of what you can’t make to
work.
>It is perfectly "stable", I use it all the time in
production code (although I’d kill the guy who suggested the
modifications to the way sizers are >handled ).
). Here “stable” does not mean what you think you mean: