Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2000-03

ExcludeClipRect function

5 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Peter Dyson
to Shane Miller: Anyone have an idea on how this works? Your supposed to send it the hdc, left,…

----- Original Message -----

Earlier message 43 lines
From: Shane Miller To: Sent: Tuesday, March 14, 2000 3:07 PM Subject: [lazarus] ExcludeClipRect function > Anyone have an idea on how this works? Your supposed to send it the hdc, left, right,top, bottom and it'll exclude this rect from the structure that is going to be painted. The problem is that I don't know where to look for that structure. I thought it was help in the DC but I don't see it in our implementation. > > Understand what I mean? If I send you a rect to exclude you need the original rect in order to change it to exclude the one I sent you. WHere is the original? > > Shane > Well it will probably be a while before any of this gets implemented. Basically it stops windows from attempting to render the parent region for that rect. This is part of the window rendering optimization. As I am still building the support for rect window painting optimizations routines, these have to be fully working before regions can be even attempted. Most of this stuff relies on the underlying desktop manager exposing this type of window drawing optimization. It may not be possible with all window mangaers to get a mapping to such fuctionality. The workaround would be the parent window sending internal paint messages to all child graphical controls using its device context and the child draws within its own rect only. IE no reliance on having a clip rect to play with. This is how most 'lightwieght' controls in MFC & VB work at least. Lightwieght graphical controls do not have their own window but are reliant on the parent for the device context etc. The handle they are allocated is used internally and not through normal windows handles. Regions will be a real pain to implement and frankly if we come up with a generic quick enough workaround then we ought to stick with it, as I said not all desktop managers may give the option for this lightweight control scenario. Peter.

Reply by email

Shane Miller

Anyone have an idea on how this works? Your supposed to send it the hdc, left, right,top, bottom and it'll exclude this rect from the structure that is going to be painted. The problem is that I don't know where to look for that structure. I thought it was help in the DC but I don't see it in our implementation.

Understand what I mean? If I send you a rect to exclude you need the original rect in order to change it to exclude the one I sent you. WHere is the original?

Shane

>> 03/13/00 05:59PM >>>

Hi,

latest changes:

Finished hide caret
Now the caret background is restored and the caret is only drawn if the control has focus. In the old editor this results in a caret which is initial not visible (only after the first pressed key). In the new editor, the behaviour is as expected.

Marc

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Reply by email

Peter Dyson
to Shane Miller

----- Original Message -----

Earlier message 46 lines
From: Shane Miller To: Sent: Tuesday, March 14, 2000 3:07 PM Subject: [lazarus] ExcludeClipRect function > Anyone have an idea on how this works? Your supposed to send it the hdc, left, right,top, bottom and it'll exclude this rect from the structure that is going to be painted. The problem is that I don't know where to look for that structure. I thought it was help in the DC but I don't see it in our implementation. > > Understand what I mean? If I send you a rect to exclude you need the original rect in order to change it to exclude the one I sent you. WHere is the original? Ok I have been looking into this a bit deeper. Here is what I think is happening. Originally MS used to do graphical controls by ensuring they got in the paint msg list before the parent, and used Exlude rect to stop the parent from overwriting. After all if the child got the message and returned msg handled the parent would never have painted. Later however they now have toolbars with backgrounds which means the parent has to draw first, and the child(which is not a window) gets to draw next, doing transparent drawing. This must mean they now generate private msgs to children that are not full windows ( which never ever get a paint msg from the desktop handler) I think we ought to take the second approach to grahical controls. This should deprecate the need for ExcludeClipRect functions completely. We can handle other broken code in a more kludgy way later, keeping the LCL controls with a clean design. This would also mean that a container syle control has to keep track of grahical controls and send it internal msgs for mouse movement paint et al. Handling graphical controls in this fashion is much cleaner and easier than trying to build all the older API which are probably not used much except for compatibity with older versions of windows. The other alternative is to make a graphical control a full window and lose the windows optimisation part of graphical controls, and possible compatibilty. Peter

Reply by email

Michael A. Hess
to Marc Weustink: + From: Shane Miller + + Anyone have an idea on how this works? Your supposed to send +…
Marc Weustink wrote 6 lines
I just looked at the docs, and I think I know what you mean. In GDK you can set the clip_rectangle/clip_region, but you can't get it (as far as I can see now). This means that functuions like ExcludeClipRect/IntersectClipRect/SelectClipRgn should maintain a ClipRect (in TDeviceContext) and pass this one to gdk.

I believe the above is the only solution. I too just went through the docs and you can set the clip_region, clip_mask, and clip_rect but it provides no means to retrieve what has already been set. You can only remove the currently set value.

Unless I also missed something in the docs. :-)

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email

Marc Weustink
to Shane Miller: Anyone have an idea on how this works? Your supposed to send it the hdc, left,…

+ From: Shane Miller
+
+ Anyone have an idea on how this works? Your supposed to send
+ it the hdc, left, right,top, bottom and it'll exclude this
+ rect from the structure that is going to be painted. The
+ problem is that I don't know where to look for that
+ structure. I thought it was help in the DC but I don't see
+ it in our implementation.
+
+ Understand what I mean? If I send you a rect to exclude you
+ need the original rect in order to change it to exclude the
+ one I sent you. WHere is the original?

I just looked at the docs, and I think I know what you mean. In GDK you can set the clip_rectangle/clip_region, but you can't get it (as far as I can see now). This means that functuions like
ExcludeClipRect/IntersectClipRect/SelectClipRgn should maintain a ClipRect (in TDeviceContext) and pass this one to gdk.

When I'm at home I'll look if it is possible to retrieve the gdk clip rect.

Marc

Reply by email