Do you have an other thread?
May be concurrency problems?
On Wed, 2014-03-05 at 01:43 -0500, Chris Moller wrote:
> Okay, I'm out of ideas...
>
> I'm writing an app, that among a lot of other stuff, has three mutually
> interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
>
On Thu, Mar 6, 2014 at 6:27 AM, Chris Moller wrote:
> On 03/05/14 13:52, Chris Angelico wrote:
>>
>> Is there a reason you're trying to write high-level code in C?
>
>
> Habit, mostly. I've been coding in C since the early 80s and I can do it in
> my sleep. Python's okay, but I tend to think of
On 03/05/14 13:52, Chris Angelico wrote:
On Thu, Mar 6, 2014 at 5:43 AM, Chris Moller wrote:
gcc supports nested functions as an extension to standard C. I tend to use
them a lot because they operate within the stack frame of the enclosing
function, thereby minimising the amount of information
On Wed, 05 Mar 2014 13:43:29 -0500
Chris Moller wrote:
> On 03/05/14 12:07, Chris Vine wrote:
> > On Wed, 05 Mar 2014 09:44:48 -0500
> > Chris Moller wrote:
> >> I was actually writing that testcase when I found a correlation:
> >> I'm using gcc and my callbacks were nested functions. Pull the
On Thu, Mar 6, 2014 at 5:43 AM, Chris Moller wrote:
> gcc supports nested functions as an extension to standard C. I tend to use
> them a lot because they operate within the stack frame of the enclosing
> function, thereby minimising the amount of information you have to pass.
> This is especiall
Le 05/03/2014 19:43, Chris Moller a écrit :
> [...]
>
> gcc supports nested functions as an extension to standard C. I tend to
> use them a lot because they operate within the stack frame of the
> enclosing function, thereby minimising the amount of information you
> have to pass. This is especi
On 03/05/14 12:07, Chris Vine wrote:
On Wed, 05 Mar 2014 09:44:48 -0500
Chris Moller wrote:
I was actually writing that testcase when I found a correlation: I'm
using gcc and my callbacks were nested functions. Pull the callbacks
out and make them normal, top-level, functions, and it all works
Le 05/03/2014 18:07, Chris Vine a écrit :
> On Wed, 05 Mar 2014 09:44:48 -0500
> Chris Moller wrote:
>> I was actually writing that testcase when I found a correlation: I'm
>> using gcc and my callbacks were nested functions. Pull the callbacks
>> out and make them normal, top-level, functions,
On Wed, 05 Mar 2014 09:44:48 -0500
Chris Moller wrote:
> I was actually writing that testcase when I found a correlation: I'm
> using gcc and my callbacks were nested functions. Pull the callbacks
> out and make them normal, top-level, functions, and it all works even
> without no blocking of
On Thu, Mar 6, 2014 at 1:44 AM, Chris Moller wrote:
> I was actually writing that testcase when I found a correlation: I'm using
> gcc and my callbacks were nested functions. Pull the callbacks out and make
> them normal, top-level, functions, and it all works even without no blocking
> of any ki
I was actually writing that testcase when I found a correlation: I'm
using gcc and my callbacks were nested functions. Pull the callbacks
out and make them normal, top-level, functions, and it all works even
without no blocking of any kind. So, if this is a bug at all, I suppose
it could be a
Dne 05.03.2014 (sre) ob 18:38 +1100 je Chris Angelico napisal(a):
> On Wed, Mar 5, 2014 at 6:29 PM, Tristan Van Berkom
> wrote:
> > Interesting, if I were you I would try to share the same adjustment
> > between all of your views.
> >
> > I.e. I would keep the adjustment in the finest grained unit
On Tue, Mar 4, 2014 at 10:43 PM, Chris Moller wrote:
> Okay, I'm out of ideas...
>
> I'm writing an app, that among a lot of other stuff, has three mutually
> interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
> then updates values in B and C. B and then would try to update
On Wed, Mar 5, 2014 at 6:29 PM, Tristan Van Berkom
wrote:
> Interesting, if I were you I would try to share the same adjustment
> between all of your views.
>
> I.e. I would keep the adjustment in the finest grained unit of each
> unit you want to display, and have your spin buttons format the val
On Wed, 2014-03-05 at 02:20 -0500, Chris Moller wrote:
> On 03/05/14 02:01, Chris Angelico wrote:
> > On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller wrote:
> >> I'm writing an app, that among a lot of other stuff, has three mutually
> >> interacting spinbuttuns, i.e., if I increment spinbutton A, it
On Wed, Mar 5, 2014 at 6:20 PM, Chris Moller wrote:
> No, they're not the same value. They're all for setting an angle, in
> radians, pi-radians, and degrees, and I want the user to be able to set the
> angle in any unit and have the equivalent angle in the other units show up
> in the other spin
On Wed, 2014-03-05 at 18:01 +1100, Chris Angelico wrote:
> On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller wrote:
> > I'm writing an app, that among a lot of other stuff, has three mutually
> > interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
> > then updates values in B and C
On 03/05/14 02:01, Chris Angelico wrote:
On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller wrote:
I'm writing an app, that among a lot of other stuff, has three mutually
interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
then updates values in B and C. B and then would try to
On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller wrote:
> I'm writing an app, that among a lot of other stuff, has three mutually
> interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
> then updates values in B and C. B and then would try to update A, and C,
> etc., resulting in
Okay, I'm out of ideas...
I'm writing an app, that among a lot of other stuff, has three mutually
interacting spinbuttuns, i.e., if I increment spinbutton A, its callback
then updates values in B and C. B and then would try to update A, and
C, etc., resulting in a bottomless recursion. So, w
> > Is this possible in C++?
>
> I suppose the Gtkmm list would be more appropriate for this.
> But if you mean `in C++ not using C++ bindings' -- what
> problems you got into?
Thread moved to gtkmm-list. Thanks.
ralf
___
gtk-app-devel-list mailing l
On Fri, Nov 17, 2006 at 09:31:35AM +0100, Ralf Stephan wrote:
>
> Is this possible in C++?
I suppose the Gtkmm list would be more appropriate for this.
But if you mean `in C++ not using C++ bindings' -- what
problems you got into?
Yeti
--
Whatever.
_
> - use g_signal_add_emission_hook() to catch all emissions of
> a signal for all instances
>
> - use g_signal_list_ids() to get all signals that objects of
> a given type can emit and then connect to them in a loop
> for an instance; note you have to recusrsively scan parent
> classes and
On Thu, Nov 16, 2006 at 08:20:34PM +0530, natarajan wrote:
>Is there a place where I can find information about the sequence of
> signals that will be emitted when a widget is created / destroyed and
> also which signal is to be used for what purpose ?
Not exactly, but see
http://develope
Hi,
Is there a place where I can find information about the sequence of
signals that will be emitted when a widget is created / destroyed and
also which signal is to be used for what purpose ?
Also is there anything like a hook which I can use to capture any signal
emitted for an widget ?
M
On Tue, 2005-02-08 at 20:57 -0500, Havoc Pennington wrote:
> > - Between the time a widget is destroyed, and the time that "dispose"
> > is called, is it possible for other signals to be serviced? That is,
> > is it best to explicitly disconnect signal handlers before destroying
> > a widget
On Tue, 2005-02-08 at 20:00 -0500, Brian Hanley wrote:
> - When does GTK service the event queue? More specifically, what GTK
> calls
> could be interrupted in order to call callbacks for GTK signals?
Signals are not in any way asynchronous (there are no threads, and they
aren't
Hi All,
I had a few questions about both (i) GTK signal handling, and
(ii) the widget destruction/disposal/finalization process.
- When does GTK service the event queue? More specifically, what GTK
calls
could be interrupted in order to call callbacks for GTK signals?
- When a widget is
28 matches
Mail list logo
