My comment below.
On Fri, Nov 11, 2016 at 9:59 PM, Bruce & Breeanna Rennie <
bren...@dcsi.net.au> wrote:
> Good afternoon to all,
>
> I have modified the original example program that Steve submitted to the
> following
>
> procedure main()
> local w, el := list(), pl := list()
> w := open("resize", "g", "size=400,400", "resize=on")
> while push(pl,Pending(w)) do {
> push(el,Event(w))
> x := WAttrib(w, "width");
> WAttrib(w, "size="||x||","||x)
> write("pl:", ximage(pl))
> write("el:", ximage(el))
> }
> close(w)
> end
>
> link ximage
>
>
> When I run this with the following command line
>
> test021 >test021.out
>
> I get the output as shown in the attached file. When one looks at the
> file, one notices that Pending() returns the same list each time and not a
> new list.
That is correct. Pending() returns the window's event queue if the queue
has any events, otherwise it fails. You could replace the while push above
with L := Pending() and you'd have access to the event queue directly. each
event code in the list is followed by the x/y mouse pointer location - I
think - of where the event took place. You can also create artificial event
by pushing values directly to the list or via Pending() itself something
like:
Pending(w, -10, 100, 200)
--Jafar
The values contained in this list are updated by Pending(). When it starts
> its good vibration mode, on each call it returns the alternate extremes.
> The other thing noticed is that Pending() appears to block while waiting to
> return some events.
>
> regards to all
>
> Bruce Rennie
>
>
> On 12/11/16 07:31, Bruce & Breeanna Rennie wrote:
>
>> Good morning all,
>>
>> I have just run another test in which I simply doubled up the Wattrib().
>> Even though, it still occasionally will exhibit the problem, it
>> stabilises fairly quickly (less than 1 sec). On some occasions, the
>> display will have the starting size and on other occasions it will have
>> the finishing size (when the problem exhibits itself).
>>
>> I still only get the problem if the movement is a quick flick and
>> release, so I don't know why there would be a difference between Steve's
>> system 64 Centos 7 and mine 32 Centos 6.7. Unless, it is related to the
>> fact that my system is much slower overall.
>>
>> I will try a test later today with seeing what events are seen in the
>> unicon program. There may be some obvious problem when this is analysed.
>> If I find anything, I'll get back to the list.
>>
>> regards
>>
>> Bruce Rennie
>>
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
