Now that's what I call a fast and detailed response - many thanks. To be fair I probably can live within those constraints - an integral part of my program is a "week per view diary" and each event appears as a button, moved and sized to represent its start and end times (bit like Outlook). All of the buttons are also connected via HOTITEM so I can give full details of the event in a text field. Press the button to edit the diary event. Can't see many people having more than say 60 events in a week but I don't like my code to be constrained so went way over the top. Most of the buttons remain hidden. Imagine every 5-minute slot having a unique event ... that's 288 events a day. But it's not going to happen.
Many thanks for all the pixel-level methods. Development of the above has been interspersed with much grinding of teeth and pulling of hair, accompanied by "why can't I just use pixels all the way?" ... Many thanks for agreeing, even if it is a bit of a re-write for me ;-) On the "flashing" problem, a bit of a play established that it was indeed continually calling "onresize". A part of my onresize method tests the size of the dialog and forces a minimum size for the dialog by forcing another resize if the user makes it too small (can this minimum size for a dialog be set somewhere? Can't see it in the doc). In 4.1.0 my code works fine, and in 4.2.0 even though I set the size big enough not to trigger another forced resize, it still attempts to resize the dialog again. The work-around is to test if the new size is less than my minimum and then resize to a bit bigger than that. To be honest, I don't think this is your problem and my re-write to use pixels everywhere will cure it anyway. There is another issue which has cropped up - following the lead from one of the sample programs supplied (dlgareaudemo.rex), I use PEEKDIALOGMESSAGE to make sure there isn't another resize message on its way - my onresize takes about 1/4 second to execute so I don't want it continually running as the user slowly drags the edge. (BTW it takes about half that time in 4.2.0 - nice one!). I see from the documentation that this now always returns empty string. Is there a different way to find out my onresize is about to be immediately followed by another one? It really looks awful and takes ages to catch up at the moment. In summary - I can live with the constraints but will raise a bug if you want me to. Don't worry about the flashing unless you want to! Can I tell if another resize is coming, and can I set a minimum size for a dialog? Many thanks again for the prompt and detailed reply. Dave. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Oorexx-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-users
