I have added a print preview feature to my program. The problem is, it does not display the preview document well on screen resolutions above 1920 x 1080.
Example:
Code:
QFont docFont;
docFont.setPointSize(14);
QTextDocument *textDoc = new QTextDocument(this);
textDoc->setDefaultFont(docFont);
textDoc->setPlainText(getHardwareData());
During a debugging process I have found the following issues:
QWindowsMultiFontEngine::loadEngine: CreateFontFromLOGFONT failed for "Courier": error 0x88985002 : Indicates the specified font does not exist.
QWindowsMultiFontEngine::loadEngine: CreateFontFromLOGFONT failed for "Courier": error 0x88985002 : Indicates the specified font does not exist.
Is there any hint/font to make it look well on all screens resolutions?
Edited:
I have fixed the QWindowsMultiFontEngine::loadEngine: CreateFontFromLOGFONT failed for "Courier" issue. The problem was caused by a Unicode character in Peripheral data. Now, the only thing left is to make it look better on 4K.
I have found some hack to get the toolbar actions from a print preview dialog. By adding some additional logic it fixed the issue.
QList<QToolBar*> toolbarList = printPreviewDlg->findChildren<QToolBar*>();
if (!toolbarList.isEmpty()) {
if (screenSize.width() > 1920 && screenSize.height() > 1080) {
toolbarList.first()->actions().at(0)->activate(QAction::Trigger);
} else {
toolbarList.first()->actions().at(1)->activate(QAction::Trigger);
}
}
To detect the screen size I use the native Win API methods. Now, it automatically triggers the Fit to width toolbar option and sets a better preview on 4K monitor. It works depending on the screen size. The issue is resolved.
Related
I am very new to Qt and right now we are developing an application that is using the TWAIN library to control a scanner.
By default, we assumed that the DPI setting of the scanner is set to 300.
However, if by chance, the user manually sets the scanner's DPI to 600 in the device settings, our application has to adjust accordingly.
Is there any way to know the DPI setting of the scanner internally through TWAIN? Like know what DPI setting is currently chosen.
Okay. I figured it out. It turns out that pTW_ENUMERATION has an attribute named CurrentIndex which stores the index of the chosen DPI. So from the code from How do I enumerate resolutions supported via TWAIN
TW_CAPABILITY twCap;
GetCapability(twCap, ICAP_XRESOLUTION);
TW_UINT32 res = 0;
if (twCap.ConType == TWON_ENUMERATION) {
pTW_ENUMERATION en = (pTW_ENUMERATION) GlobalLock(twCap.hContainer);
if (en->ItemType == TWTY_FIX32) {
res = ((TW_UINT32*)(en->ItemList))[en->CurrentIndex];
qDebug()<<res;
}
}
I am trying to create a simple panel for Openbox in Arch Linux using c++, but I cannot figure out how to remove the title bar from a window.
I am creating the window with XCreateWindow(...), and that gives a window with the correct size, but it contains a title bar, and the window also opens in the top-left corner of the screen, no matter what offset coordinates I specify.
I read here that both of these problems are probably caused by the window manager (Openbox), which overrides the window attributes I specified in XCreateWindow(..., &window_attributes). This could be solved by adding window_attributes.override_redirect = True;, although this does not seem to do anything for me. When I try this I get the exact same window as before. (I did compile the file after this change.)
Also I read into the code of Tint2 (link), which is another panel for Openbox. They create a window using the following code:
XSetWindowAttributes att = { .colormap=server.colormap, .background_pixel=0, .border_pixel=0 };
p->main_win = XCreateWindow(server.dsp, server.root_win, p->posx, p->posy, p->area.width, p->area.height, 0, server.depth, InputOutput, server.visual, mask, &att);
I don't see an override_redirect anywhere in their code, so I'm not sure how they are removing the title bar.
As additional information, I thought it would be worth mentioning how I'm executing the script:
/* The c++ file is saved as 'panel.cpp' */
$ gcc panel.cpp -lX11 -o panel
$ ./panel
Also, I am running Arch Linux through VirtualBox with Windows 8 as host. I'm not sure if this changes anything, but it won't hurt to mention.
Since I found the solution, I figured I'd post the solution here if anyone else needs it.
As #JoachimPileborg mentioned, I needed to alter the Openbox settings in ~/.config/openbox/rc.xml. Inside the <applications> tag, I added the following code:
<application class="*">
<decor>no</decor>
<position force="no"></position>
</application>
The class="*" means that all applications will follow these rules, you could fill in the class name of the application instead. The <decor>no</decor> removes the title bar, and <position force="no"></position> ensures that my own script is able to handle the positioning. You could also add another <application> tag after this one to make exceptions to this rule.
Also, the window_attributes.override_redirect = True; is not needed anymore.
A more correct way is to use the Extended Window Manager Hints.
The idea is that you don't tell the window manager how to decorate or not your window, you just indicate the window type with _NET_WM_WINDOW_TYPE :
Atom window_type = XInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
long value = XInternAtom(display, "_NET_WM_WINDOW_TYPE_DOCK", False);
XChangeProperty(display, your_window, window_type,
XA_ATOM, 32, PropModeReplace, (unsigned char *) &value,1 );
"Dock" is the type for panels and taskbar. Usually they are undecorated and appear on all desktops. As written on the documentation, previously the _MOTIF_WM_HINTS property was used to define the appearance and decorations of the window. Window managers still support it, but _NET_WM_WINDOW_TYPE is prefered as it describe the function and let the window manager (and user) decide on the appearance and behavior of that type of window.
Another interesting property for a panel is _NET_WM_STRUT_PARTIAL, to "reserve" space.
I have a button in one of view controller of tab bar controller. All set up in storyboard. I registered action method like this
- (IBAction)buttonPressed:(id)sender {
NSLog(#"Button pressed");
}
The thing is that once I make left and top constraints (to force it stay in the right upper corner) touch up inside event stops working after I change rotation. So just open app in portrait mode - method is working. Change to landscape and I cannot tap button suddenly.
I've recreated problem in this easy example project.
Many thanks.
Just put the following code in you TabBarViewController class.
- (void)viewDidLayoutSubviews
{
// fix for iOS7 bug in UITabBarController
self.selectedViewController.view.superview.frame = self.view.bounds;
}
Recently I noticed same bug in my application. First I tried Slavco Petkovski method. But this caused me another bug with rotating and getting right bounds and frame, so I kept searching.
I found another solution for this problem, mainly setting autoresizing mask of view controller's view in xib. But since arrows in inspector in my Xcode (version 5.0.1) are inactive and you can't set them, you have to open xib file in text editor find autoresizingMask property for main view and change it like this:
<autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/>
EDIT:
Alternatively you can do this in your view controller's code - same result as in changes in xcode:
self.view.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
This occurs using a few apks that make use of the camera (e.g., zxing, opencv). It displays a glitched image in the preview but it is still a function of what the camera sees so it appears to be an encoding mismatch. The native camera preview works fine, so the internal apps do not exhibit this problem.
For now, please try adding the following workaround after you acquire the Camera but before you setup and start the preview:
Camera.Parameters params = camera.getParameters();
params.setPreviewFpsRange(30000, 30000);
camera.setParameters(params);
(Or just add the setPreviewFpsRange call to your existing parameters if you're setting others as well.)
For anyone using ZXing on their Glass, you can build a version from the source code with the above fix.
Add the following method into CameraConfigurationManager.java
public void googleGlassXE10WorkAround(Camera mCamera) {
Camera.Parameters params = mCamera.getParameters();
params.setPreviewFpsRange(30000, 30000);
params.setPreviewSize(640,360);
mCamera.setParameters(params);
}
And call this method immediately after anywhere you see Camera.setParameters() in the ZXing code. I just put it in two places in the CameraConfigurationManager and it worked.
I set the Preview Size to be 640x360 to match the Glass resolution.
30 FPS preview is pretty high. If you want to save some battery and CPU, consider the slowest supported FPS to be sufficient:
List<int[]> supportedPreviewFpsRanges = parameters.getSupportedPreviewFpsRange();
int[] minimumPreviewFpsRange = supportedPreviewFpsRanges.get(0);
parameters.setPreviewFpsRange(minimumPreviewFpsRange[0], minimumPreviewFpsRange[1]);
The bug still exists as of XE16 and XE16.11 but this code gets past the glitch and shows a normal camera preview, note the three parameter setting lines and their values. I have also tested this at 5000 (5FPS) and it works, and at 60000 (60FPS) and it does not work:
public void surfaceChanged(SurfaceHolder holder, int format, int w, int h) {
if (mCamera == null) return;
Camera.Parameters camParameters = mCamera.getParameters();
camParameters.setPreviewFpsRange(30000, 30000);
camParameters.setPreviewSize(1920, 1080);
camParameters.setPictureSize(2592, 1944);
mCamera.setParameters(camParameters);
try {
mCamera.startPreview();
} catch (Exception e) {
mCamera.release();
mCamera = null;
}
}
This still is an issue as of XE22 (!) Lowering the frames per second to 30 or lower does the trick:
parameters.setPreviewFpsRange(30000, 30000);
And indeed, don't forget to set the parameters:
camera.setParameters(parameters);
I have found no clear explanation as to why this causes trouble, since 60 fps is included in the supported fps range. The video can record 720p, but I never saw a source add the fps to this.
You can set the params.setPreviewSize(1200,800). You can change the values around this range until you can clear color noise.
Using CWnd::ShowWindow(SW_SHOWMAXIMIZED) maximizes my app window as expected.
However, when clicking the restore button on the app (or double clicking the title-bar), the restored size is the same size as the maximized window, which is confusing for the user.
Using this alternative code has the same problem:
WINDOWPLACEMENT wndpl;
GetWindowPlacement(&wndpl);
wndpl.showCmd = SW_SHOWMAXIMIZED;
SetWindowPlacement(&wndpl);
How can I keep the default un-maximized size when restoring.
I've solved my problem, and the solution might solve yours too. My problem was that even though I called SetWindowPlacement(&wndpl) within CMainFrame::OnCreate the window was not properly restored if it was maximized. I added two lines of code before SetWindowPlacement, and now it works as expected.
CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
...
// Obtain wndpl, maybe from registry
AfxGetApp()->m_nCmdShow = wndpl.showCmd;
wndpl.showCmd = SW_SHOW;
SetWindowPlacement(&wndpl);
}
These two lines helps underlying code not to mess things up when calling ActivateFrame, which calls ShowWindow with parameter obtained from CWinApp::m_nCmdShow.
All information are in the file with extension .RC. I never used a Maximize/Restore procedures though you should look for a 'DIALOGEX' for the same window. You can change it using any editor (notepad, ultraedit etc.)