I have a problem with MFC dialog boxes that are drawn using derived MFC classes for custom drawing of controls.
One of our customers has a real slow PC with a poor graphics card and even normal Windows dialogs paint quite slow. In our case, the problem is far worse. Each individual control (e.g. buttons, group boxes, labels) can be seen to draw seperately.
In most cases I've overridden/implemented the OnPaint() handlers, thinking that drawing on whatever device context I'm provided should be the way to go.
Ideally, what I would like to do is have all controls painted on an off-screen buffer so that when a dialog repaint is required - bang - it just copies the single rendered image to the screen, rather than painting each control to the screen one by one.
Can somebody please advise me how I can achieve this kind of double-buffering?
I've sort of found the solution to my problem.. By setting the dialog extended style to WS_EX_COMPOSITED, the drawing works nicely.. The problem I'm having now concerns a continuous stream of WM_PAINT and WM_ERASEBKGND messages that I keep getting when this style is enabled.
Does anyone know how I can stop the WM_PAINT/WM_ERASEBKGND messages from continously occurring?
Related
I would like to draw some sort of window on top of all the other windows. For example, to display some debugging infos (like conky) or things like a timer.
The main thing is that I would like to able to continue using the other windows while using it (the events go through transparently).
I've tried doing it with pygtk, pyqt and others but can't find a way to make it a real overlay with no event capture.
Is there some low-level x11 solution?
I think the Composite-extension-approach will not work when a compositing manager is running (and thus Composite's overlay window is already used).
Since you explicitly mention "no event capture":
The SHAPE extension allows to set some different shapes for a window. Version 1.1 of this extension added the "input" shape. Just setting this to an empty region should pretty much do what you want.
Some concrete example of exactly what I think you ask for can be found in Conky's source code: http://sources.debian.net/src/conky/1.10.3-1/src/x11.cc/?hl=769#L764-L781
Edit: Since you said that you didn't find anything in Gtk (well, PyGtk), here is the function that you need in Gtk: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-input-shape-combine-region
You might need Composite extension + GetOverlayWindow request:
Version 0.3 of the protocol adds the Composite Overlay Window, which
provides compositing managers with a surface on which to draw without
interference. This window is always above normal windows and is always
below the screen saver window. It is an InputOutput window whose width
and height are the screen dimensions. Its visual is the root visual
and its border width is zero. Attempts to redirect it using the
composite extension are ignored. This window does not appear in the
reply of the QueryTree request. It is also an override redirect
window. These last two features make it invisible to window managers
and other X11 clients. The only way to access the XID of this window
is via the CompositeGetOverlayWindow request. Initially, the Composite
Overlay Window is unmapped.
CompositeGetOverlayWindow returns the XID of the Composite Overlay
Window. If the window has not yet been mapped, it is mapped by this
request. When all clients who have called this request have terminated
their X11 connections the window is unmapped.
Composite managers may render directly to the Composite Overlay
Window, or they may reparent other windows to be children of this
window and render to these. Multiple clients may render to the
Composite Overlay Window, create child windows of it, reshape it, and
redefine its input region, but the specific arbitration rules followed
by these clients is not defined by this specification; these policies
should be defined by the clients themselves.
C api : XCompositeGetOverlayWindow
PyGTK Solution:
I think the composite and shapes X extensions are sufficiently ubiquitous and shall assume here that they are active on your system. Here's PyGtk code for this:
# avoid title bar and standard window minimize, maximize, close buttons
win.set_decorated(False)
# make the window stick above all others (super button will still override it in the z-order, which is fine)
win.set_keep_above(True)
# make events pass through
region = cairo.Region(cairo.RectangleInt(0, 0, 0, 0))
my_window.input_shape_combine_region(region)
win.show_all()
# set the entire window to be semi-transparent, if we like
win.set_opacity(0.2)
Basically what this does is tell Gtk that other than pixel (0,0) the entire window my_window should not be considered part of itself in terms of event propagation. That in turn, according to my current understanding means that when the pointer moves and clicks, the events go to the underlying window under the pointer position, as if my_window was not there.
Caveat:
This does allow your overlay window being the focus window (due to user-solicited window switching or just because it pops up and gets the focus when your application starts). Which means that for example, keyboard events will still undesirably go to it up until the user has clicked through it to make it lose focus in favor of whatever window is under the cursor. I would likely use the approach described here to iron out this aspect.
If there's a different and proper approach for making a portion of the screen "display stuff but not receive events", without building an oddball window like above over it, I'm happy to learn about it.
I assume that one's particular desktop environment (gnome, unity, etc. on linux) may interfere with this solution depending on version and configuration, on some occasions.
I'm writing an application with a material design layout, but can't find any guidelines on how to animate dialog boxes onto the screen.
This suggests that the box should just "ping" into existence, but that seems to go against the ethos of the design, with its animations and tactile feel.
Does anyone have more information on what the correct course of action is?
Here are the specs for dialog boxes, by the way: http://www.google.co.uk/design/spec/components/dialogs.html#dialogs-specs
I took a look at existing Google apps, and it appears that the dialog box fades in at full size. The transition is pretty quick, like 0.25 seconds.
If you go into Developer Options and change Window animation scale to 10x, it will slow things down enough for you to see it clearly.
I chose Google Calendar > New Event, then select the different fields to see the dialog appear.
Here's a screen recording I did that shows the animation.
https://www.youtube.com/watch?v=jbU5yRhSbKg
Just started working with this awesome external but have a couple of questions.
When the control is evoked, is it always the top layer or can I have a background transparent image on top of it so I can frame the control nicely?
Also, my testing seems to read most Barcodes but when it comes down to reading Barcodes on hard drives, the control does not want to decode those.... Too dense of bar code pattern?
I am very impressed thus far with the ease of use of your externals. Makes we want to code more for mobile devices!
an overlaying transparent image is not possible, as far as i know.
but couldn´t you use
command mergZXingControlSetRect pLeft,pTop,pRight,pBottom
to define the rect of that scanner after creation
or
command mergZXingControlCreate pLeft,pTop,pRight,pBottom
to create the scanner control in the specified rect.
Set the rect smaller than the width and the height of the screen.
You could then use an underlying image, which is displayed outside of the scanner rect, to show the frame around scanner control. Did not test it myself, but i would assume that this should work.
Unfortunately the native controls in externals and the ones the engine provides are added as views on top of the LiveCode view. That means you can't intermingle LiveCode controls with them. One thing that some users have done is add a web view with a transparent background and a load a png image. If you create the barcode view first and the web view second then the web view will be on top.
I have a game Activity, which contains a SurfaceView that fills the whole screen.
The app is declared as fullscreen, and appears as such.
My SurfaceView has an OnTouchListener, which feeds a GestureDetector, with a functionality that works fine on most devices.
The listener is set as simply as:
surface.setOnTouchListener(listener);
However, on Jelly Bean (Nexus 4) , touching the soft buttons (back, home, etc.) generates a touch event in coordinates that are irrelevant to my SurfaceView.
This currently generates weird behaviors.
I can workaround that by simply doing a check on touch events and see if they fit the surface size.
However, I was wondering if there is a more elegant solution - one that will just give me the touch events ONLY from my surface and not from those soft buttons.
This is also crucial in the case that some future devices do different variations of that (putting the soft buttons in the UPPER area, for example).
I am creating a project similar to task manager,
Now I want to draw a graph to that show cpu usage.
My problem is that I dont have any knowledge about painting in vc++,
but my idea is that I should first make a grid like in task manager but I dont have any pixel information,
So plese tell me how to find the pixel value if the Picture control.
Rather than trying to manipulate what's on screen what you need to do is a create a bitmap in memory using CBitmap::CreateCompatibleBitmap and BitBlt when Windows sends a WM_PAINT message.
This question looks at how to subclass a CStatic control (ie a picture control) to draw onto a dialog by handling WM_PAINT messages:
Handling WM_PAINT in a Subclassed CStatic Control
You just need to add the bitmap painting bit.