It must be scanned, so you shouldn't specify NO_SCAN attribute,
it's for memory blocks, which are guaranteed to not hold pointers
to GC memory, like ubyte[] buffers for i/o, so managed blocks can
be safely collected without looking at content of NO_SCAN blocks.
On Tuesday, 13 May 2014 at 18:47:45 UTC, Gary Willoughby wrote:
They are not bound automatically but may be bound later.
So they will be allocated on demand - only if it's bound, Args
will be allocated, so widget will have only one Args allocated,
or as many as were actually bound. Or do you
On Wednesday, 14 May 2014 at 07:11:45 UTC, Kagamin wrote:
It must be scanned, so you shouldn't specify NO_SCAN attribute,
it's for memory blocks, which are guaranteed to not hold
pointers to GC memory, like ubyte[] buffers for i/o, so managed
blocks can be safely collected without looking at
Do you always bind all of them?
Another option is to allocate from pool.
On Tuesday, 13 May 2014 at 06:27:14 UTC, Kagamin wrote:
Do you always bind all of them?
They are not bound automatically but may be bound later. You can
bind to events such as mouse-enter, mouse-click, keypresses, etc.
In fact this is how keyboard shortcuts are handled.
I've added a
Based on this conversation in another thread:
http://forum.dlang.org/thread/wdddgiowaidcojbrk...@forum.dlang.org?page=5#post-yjmrqgesjtadecutvkye:40forum.dlang.org
I've realised i may have a nasty bug lurking in the code. Now i
want to completely understand what is happening.
Take the
AFAIK, addRoot is for memory allocated in GC heap, and addRange
is for other types of memory, so you can't add non-gc memory as
root (just a guess, see docs). I would allocate whole Args in GC
heap and add is as root, yes, it would prevent collection until
the root is removed. A better way
On Monday, 12 May 2014 at 19:13:28 UTC, Kagamin wrote:
AFAIK, addRoot is for memory allocated in GC heap, and addRange
is for other types of memory, so you can't add non-gc memory as
root (just a guess, see docs). I would allocate whole Args in
GC heap and add is as root, yes, it would prevent
Why many? I'd say, you typically have 0 subscriptions (label,
textbox) per widget, seldom - 1 (button, combobox, checkbox).
combobox and checkbox usually don't require a subscription
either. Only button requires a reaction from your code,
everything else usually works on its own.
On Monday, 12 May 2014 at 20:03:46 UTC, Kagamin wrote:
Why many? I'd say, you typically have 0 subscriptions (label,
textbox) per widget, seldom - 1 (button, combobox, checkbox).
There are many events that can be bound to on any widget.
12 matches
Mail list logo
