I have a problem in printing right to left in my application. I use the codejock report control; it prints the left to right view very well and this is an example:
When the layout is rtl the control renders very well on the screen and also the print preview is fine, but printing results in a distorted document like the following:
I have tried to override the OnPrepareDC of the view and used the pDC->SetLayout(LAYOUT_RTL) but it failed, I need help on how to fix this.
Actually I have found a solution for RTL printing issue.
the reason of the problem is that not all the printer's drivers support mirroring so calling the SetLayout(RTL) function on the printer's DC will not work in all printer's drivers.
The first step is not to call SetLayout(RTL) at all,
then you should override drawing methods in report paint manager class to set the alignment of each drawing rectangle when you are in RTL printing mode.
Related
There are many demonstration units provided by both Embarcadero and other third parties for auto-scrolling on showing the Android virtual keyboard.
However non work correctly when working in landscape mode. Even if you manage to get the top of the memo visible, changing line will render the control out of sight, or you try and stay with the caret position and find the offset is wrong, manually correcting this causes issues with different resolutions.
Is there any article / component / code example, that anyone has seen, which solves this problem. I would opine that something so simple should be already resolved in the examples with RAD Studio, but alas it is not.
I am using native controls but am more than happy to switch back to Firemonkey styled controls if required.
Thank you in advance.
I'm trying to develop a report in Delphi XE4 and Report Builder 15.01 using CodeBar component.
When I print to screen the print is normal, but when I send that print to the printer, the codebar component disappear from the print, leaving just a blank space in its place.
I'm not changing its properties in runtime.
What could it be?
Edit:
The CodeBar component only disappear when the device is "Printer", if I change it to PDF for example, it prints correctly.
Edit2:
I have found another behavior: the Codebar doesn't disappear, it creates another codebar inside, with the same properties, but just visually. I could post images to make thing much clearer but i don't have anough rep points. lol.
Edit3:
I have tryed the version 14 and for my surprise the problem doesn't exist. I guess it's a bug from RB.
Well, after changing the version to 14 the problem has been solved. Not only this problem but some others layout problems.
it should be simple but I don't find how to do it.
I create a form with a right aligned panel that I color in blue for example.
If I grab my forms left edge and resize it back and forth horizontally quickly, I would like the right panel not to move or flicker. As its position is unchanged, there is no reason why it should not stay completely steady. Does anybody know a simple trick to solve this apparently simple problem?
Thanks
This is just a fact of life with Windows GUI apps. You can see the same effect in a WinForms app and indeed even in mainstream Windows apps. For example, open an Explorer window and do exactly the same operation, resize by grabbing the left hand edge of the window. You will see exactly the same effect. You can see the same effect by resizing from any edge. Word and Excel behave in the same way.
My guess is that Windows repaints in the sizing loop before it sends the resizing message that allows the app to realign its controls.
With Delphi 7 trying to change the color of the title bar of the software from the window theme. I have seen code which allows you to change ALL the title bars of all programs, but I am just wanting to change my program.
Anyone seen/done anything like this? Don't mind paying for a component if needed.
I believe Windows sends the WM_NCPAINT message to an application when it should paint the window frame including the title bar. The default behaviour is to fall back to the default Windows handler which draws the default frame. You could replace this, or re-paint the title-bar section right after.
This looks like a good example: http://delphi.about.com/od/adptips2006/qt/draw_captionbar.htm
The answer by Stijn is not fully complete, as the caption and border of the window will also be redrawn when it is (de-)activated. So in addition to WM_NCPAINT you will also need to handle WM_NCACTIVATE. Unfortunately this can not simply be replaced, as there is other code in the default message handler (apart from drawing code) that needs to be executed. But calling the default handler will in turn lead to the default caption and border being drawn first, which you would then need to draw over with your intended colour, resulting in flicker.
One way to work around this is to adjust the drawing region that the default message handler is called with. See "Drawing titlebar on XP with themes" for an example using Windows API calls that should easily translate to Delphi. Note that this deals only with the text in the caption bar, but the principle applies.
You might take a look at a skinning library. ExpressSkin by DevExpress is a good one.
I'm trying to draw over the whole screen by using the desktop canvas and painting to it directly. The problem is I can't clear that desktop canvas. I've tried setting the canvas.pen.style to psNotXOR and draw over the old image but unfortunately, this is not reliable enough and some left overs are still present in some conditions.
My need is to draw a selection rectangle around a window / control when the mouse is over it.
You don't write on what OS you have problems with the artefacts after clearing.
At least with desktop composition activated it is a very bad idea to draw directly to the desktop and to do XOR painting (see "Drawing To and Reading From the Screen -- Baaaad!" in this blog post). Apart from the negative performance implications you can't be sure what other painting happens at the same time and what effects and animations alter the displayed content, so a simple XOR may not be enough to completely erase everything.
One possible way to implement it would be a transparent overlay window of desktop size, and to draw your rubber band selector over that. Invalidating the whole window if the size changes should be enough, no need to erase the old selection line. If the overlay is removed the line will be gone too. Desktop composition will make sure that no flicker occurs. However, switching applications while selecting an area will be problematic, you need to catch this and immediately cancel the selection.
Edit:
I just tested it with Delphi 2009, and with the following test app:
a form with FormStyle set to fsStayOnTop and with AlphaBlend set to True
with an overridden CreateParams() method to add the WS_EX_TRANSPARENT extended style flag
I can pass all mouse clicks through to the underlying windows while being able to draw into a window on top of them. This should get you started.
I've done some stuff like this in the past and I've never come up with an acceptable solution.
Having a think about it though you could send the desktop HWND an invalidate command.
Because the desktop is a modified listview control you should able to use something like
procedure InvalidateDesktop;
begin
RedrawWindow(GetDesktopWindow, 0, 0, RDW_INVALIDATE);
//if that doesn't work then try this:
//Sendmessage(GetDesktopWindow, wm_setredraw, 1, 0);
end;
That might do what you want, I haven't tested it as I've just knocked it up for the example.
the problem is that Windows won't return me the control behind the mouse
I think you need to hook the mouse event messages for this - the hooked message then gives you the window handle that the mouse is over.
Look up SetWindowsHookEx(WH_MOUSE,,,) and MOUSEHOOKSTRUCT.
This is how we do it in our app:
FBitmap.Canvas.Brush.Color := clWhite;
FBitmap.Canvas.FillRect(FBitmap.Canvas.ClipRect);