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;
}
}
Related
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.
I'm making a hobby project that is basically a bot for a very old flash game, the mouse move and click works fine, but all key presses make the operating system lag/stutter and sometimes stop listening to all keyboard inputs, real or fake.
I started using just XLib with XTests but didn't work, so I tried XSendEvent instead of XTests, but all symptoms stayed the same, so the last attempt was with XDO, which gave better results, but still freezes the OS.
this is the current snippet that I'm trying to use to simulate a keypress:
//Constructor
CheatCore::CheatCore() {
xdo_t x = xdo_new(NULL);
Window *list;
xdo_search_t search;
unsigned int nwindows;
memset(&search, 0, sizeof(xdo_search_t));
search.max_depth = -1;
search.require = xdo_search::SEARCH_ANY;
search.searchmask = SEARCH_CLASS | SEARCH_ONLYVISIBLE;
search.winclass = "Chrome";
int id = xdo_search_windows(x, &search, &list, &nwindows);
qDebug() << nwindows;
if(!nwindows){
qDebug() << "Chrome not found";
return;
}
w = list[0];
//I have to call activate twice to really bring it forward, I suspect that its
//because I use a transparent "overlay" that show stats for the cheat and it is set as Aways on top
//(i used Qt to set it to not get any Events)
xdo_activate_window(x,w);
xdo_activate_window(x,w);
}
//there is a function that executes every second to check if a pixel color has changed,
//if so, then the SendKey is called to Reload weapon magazine pressing the "space" key
void CheatCore::SendKey(){
xdo_activate_window(x,w);
xdo_activate_window(x,w);
xdo_send_keysequence_window(x, w, "space", 500);
}
I'm using a transparent overlay to show the bot status, with just some numbers appearing, it is a widget created using Qt that is AlwaysOnTop and the paint event draws the desired information's, it is another object and don't have direct impact in the CheatCore, but this is the window flags used to draw over a transparent window and ignore events.
setWindowFlags(Qt::WindowTransparentForInput | Qt::FramelessWindowHint |
Qt::WindowStaysOnTopHint);
setAttribute(Qt::WA_NoSystemBackground);
setAttribute(Qt::WA_TranslucentBackground);
setAttribute(Qt::WA_TransparentForMouseEvents);
I didn't manage to understand what could be provoking this weird behavior, could it be the windowing system?
Also, I tried to find a Qt way of simulating mouse/keyboard inputs, but i didn't manage to find any solution to send events to other windows if there is a way possible of achieving this would be great!
The game i'm trying to automate is called "Storm the House"
If interested this is the link to the online repo : link
Can you help me make this work? Thank you!
Context about the setup:
Ubuntu 18.10 using VGA and Nvidia drivers (if it may influence the xserver)
Did you ever try to use xdotool from command line. To use xdotool you need to install package first.
To simualte a key press, you can use.
xdotool key <key>
For example if you want to simulate key press for X you can use this code
xdotool key x
Or any other combination like
xdotool key ctrl+f
Also you can replace key press with another one, for example if you want to replace pressing D with Backspace you can try this one
xdotool key D BackSpace
You can read complete guid online, also you can write script with this tool and use it in many different situations.
Also you can use it for remote connection too.
I hope this helps you with your little problem.
Using evdev is a linux specific option.
It's a simpler solution as you just need to open the correct file and write to it.
Take a look at this similar question to see how to get started.
I'm migrating a Qt for iOS project to Qt 5.5. In iOS 5.1.1 at least, the app fails to start if you launch it with the device face up. An assertion displays an error in qiosscreen.mm at line 344. Here's the Qt source code function that is failing:
Qt::ScreenOrientation QIOSScreen::orientation() const
{
// Auxiliary screens are always the same orientation as their primary orientation
if (m_uiScreen != [UIScreen mainScreen])
return Qt::PrimaryOrientation;
UIDeviceOrientation deviceOrientation = [UIDevice currentDevice].orientation;
// At startup, iOS will report an unknown orientation for the device, even
// if we've asked it to begin generating device orientation notifications.
// In this case we fall back to the status bar orientation, which reflects
// the orientation the application was started up in (which may not match
// the physical orientation of the device, but typically does unless the
// application has been locked to a subset of the available orientations).
if (deviceOrientation == UIDeviceOrientationUnknown)
deviceOrientation = UIDeviceOrientation([UIApplication sharedApplication].statusBarOrientation);
// If the device reports face up or face down orientations, we can't map
// them to Qt orientations, so we pretend we're in the same orientation
// as before.
if (deviceOrientation == UIDeviceOrientationFaceUp || deviceOrientation == UIDeviceOrientationFaceDown) {
Q_ASSERT(screen());
return screen()->orientation();
}
return toQtScreenOrientation(deviceOrientation);
}
It displays an assertion at
Q_ASSERT(screen());
screen() must be returning 0, so screen()->orientation() is attempting to deference a null pointer. That screen() function is defined in the parent class, QPlatformScreen:
QScreen *QPlatformScreen::screen() const
{
Q_D(const QPlatformScreen);
return d->screen;
}
The constructor for that class initializes d->screen to 0:
QPlatformScreen::QPlatformScreen()
: d_ptr(new QPlatformScreenPrivate)
{
Q_D(QPlatformScreen);
d->screen = 0;
}
From the comments, I infer that d->screen is set at some point when the orientation is portrait or landscape, and then they fall back to that when it becomes face up / down. Since it is starting as face up, there is no prior good value to fall back to.
Has anyone else encountered this, or have a solution? Btw, I am not building from qt source and do not want to, so changing their code is not a solution for me if I can possibly avoid that.
I found that this only seems to be occurring when I launch the app from XCode or QtCreator. If I launch the app on the device the way it normally runs, this bug seems to be averted.
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.
I want to make a text replacement program for linux. ie I type something like .alog, and it gets replaced with /usr/local/apache/logs/. I know I can do this with alaises, but I am often remotely logged on machines that do not have such alaises.
I am also interested in doing this for learning purposes.
I see some info online about grab and send keystrokes in X for a window I make, but can't find info on doing it for all windows in the workspace.
Any suggestions on how to do this would be greatly appreciated.
You may wish to start with the code of a window manager as a starting point; Window Managers bind keys to work regardless of window, this is probably a good start. dwm is widely held to have beautiful code.
setup() appears to add its event mask to the root window directly:
screen = DefaultScreen(dpy);
root = RootWindow(dpy, screen);
/* ... */
/* select for events */
wa.cursor = cursor[CurNormal];
wa.event_mask = SubstructureRedirectMask|SubstructureNotifyMask|ButtonPressMask|PointerMotionMask
|EnterWindowMask|LeaveWindowMask|StructureNotifyMask|PropertyChangeMask;
XChangeWindowAttributes(dpy, root, CWEventMask|CWCursor, &wa);
XSelectInput(dpy, root, wa.event_mask);
grabkeys();