| Widget_windows, scrolling and refreshing [message #90672] |
Tue, 24 March 2015 13:39  |
PMan
Messages: 61
Registered: January 2011
|
Member |
|
|
Hello,
I have a widget_base which holds a variable number of widget_windows containing image chips. If the number of widget_windows required exceeds a threshold, the y scroll bar is enabled on the widget_base.
My problem is when the scroll bar is enabled and I actually scroll, only the top and bottom row of widget_windows refresh (i.e., the ones moving onto the visible area when scrolled). The center rows of widget_windows go black and are never refreshed.
There does not seem to be a 'scroll event' off which to cue a refresh. Any ideas how to make the black window_widgets refresh?
Thank you
|
|
|
|
| Re: Widget_windows, scrolling and refreshing [message #90673 is a reply to message #90672] |
Tue, 24 March 2015 14:07  |
Helder Marchetto
Messages: 520
Registered: November 2011
|
Senior Member |
|
|
On Tuesday, March 24, 2015 at 9:40:03 PM UTC+1, Paul Mallas wrote:
> Hello,
>
> I have a widget_base which holds a variable number of widget_windows containing image chips. If the number of widget_windows required exceeds a threshold, the y scroll bar is enabled on the widget_base.
>
> My problem is when the scroll bar is enabled and I actually scroll, only the top and bottom row of widget_windows refresh (i.e., the ones moving onto the visible area when scrolled). The center rows of widget_windows go black and are never refreshed.
>
> There does not seem to be a 'scroll event' off which to cue a refresh. Any ideas how to make the black window_widgets refresh?
>
> Thank you
I've ran into a similar problem with FG graphics and I found a workaround. I don't like it, but saves me lots of headaches. I basically fire a timer_event every second (or less... depending) and I then refresh windows using something like:
oWin->refresh
Does the job, but I would also like these window to update on their own :-)
Let me know if you have a better solution.
Cheers,
Helder
PS: This also happens with normal windows. Event if I do p=plot(/test) and then do something else, the window might go black. The only way I found to get things back is to interact with the widget (or refresh it).
|
|
|
|
| Re: Widget_windows, scrolling and refreshing [message #90674 is a reply to message #90673] |
Tue, 24 March 2015 14:59 |
PMan
Messages: 61
Registered: January 2011
|
Member |
|
|
On Tuesday, March 24, 2015 at 5:07:31 PM UTC-4, Helder wrote:
> On Tuesday, March 24, 2015 at 9:40:03 PM UTC+1, Paul Mallas wrote:
>> Hello,
>>
>> I have a widget_base which holds a variable number of widget_windows containing image chips. If the number of widget_windows required exceeds a threshold, the y scroll bar is enabled on the widget_base.
>>
>> My problem is when the scroll bar is enabled and I actually scroll, only the top and bottom row of widget_windows refresh (i.e., the ones moving onto the visible area when scrolled). The center rows of widget_windows go black and are never refreshed.
>>
>> There does not seem to be a 'scroll event' off which to cue a refresh. Any ideas how to make the black window_widgets refresh?
>>
>> Thank you
>
> I've ran into a similar problem with FG graphics and I found a workaround. I don't like it, but saves me lots of headaches. I basically fire a timer_event every second (or less... depending) and I then refresh windows using something like:
> oWin->refresh
>
> Does the job, but I would also like these window to update on their own :-)
> Let me know if you have a better solution.
>
> Cheers,
> Helder
>
> PS: This also happens with normal windows. Event if I do p=plot(/test) and then do something else, the window might go black. The only way I found to get things back is to interact with the widget (or refresh it).
Ok, I will try out your idea. The only things I could come up with were 1) creating an additional 'Refresh all' button, or 2) making the scroll range so large that everything can scroll out of/into visible range. Both sort of lousy choices.
|
|
|
|
| Re: Widget_windows, scrolling and refreshing [message #90676 is a reply to message #90674] |
Tue, 24 March 2015 15:19 |
PMan
Messages: 61
Registered: January 2011
|
Member |
|
|
On Tuesday, March 24, 2015 at 5:59:50 PM UTC-4, Paul Mallas wrote:
> On Tuesday, March 24, 2015 at 5:07:31 PM UTC-4, Helder wrote:
>> On Tuesday, March 24, 2015 at 9:40:03 PM UTC+1, Paul Mallas wrote:
>>> Hello,
>>>
>>> I have a widget_base which holds a variable number of widget_windows containing image chips. If the number of widget_windows required exceeds a threshold, the y scroll bar is enabled on the widget_base.
>>>
>>> My problem is when the scroll bar is enabled and I actually scroll, only the top and bottom row of widget_windows refresh (i.e., the ones moving onto the visible area when scrolled). The center rows of widget_windows go black and are never refreshed.
>>>
>>> There does not seem to be a 'scroll event' off which to cue a refresh. Any ideas how to make the black window_widgets refresh?
>>>
>>> Thank you
>>
>> I've ran into a similar problem with FG graphics and I found a workaround. I don't like it, but saves me lots of headaches. I basically fire a timer_event every second (or less... depending) and I then refresh windows using something like:
>> oWin->refresh
>>
>> Does the job, but I would also like these window to update on their own :-)
>> Let me know if you have a better solution.
>>
>> Cheers,
>> Helder
>>
>> PS: This also happens with normal windows. Event if I do p=plot(/test) and then do something else, the window might go black. The only way I found to get things back is to interact with the widget (or refresh it).
>
> Ok, I will try out your idea. The only things I could come up with were 1) creating an additional 'Refresh all' button, or 2) making the scroll range so large that everything can scroll out of/into visible range. Both sort of lousy choices.
Funny thing - I just 'remote desktop'ed in my computer at work. And it seems that this problem does not occur when using remote desktop. Usually for any type of graphics it's terrible, but for this, it actually fixes the problem. Go figure ...
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
