if i set printer quality = DMRES_HIGH
then also it printing in normal mode.
Possibly a bit of a daft question in return, but given the MSDN description on DEVMODE, are you sure your driver/printer supports the setting in this manner?
A printer driver supports only those
member of the DEVMODE structure that
are appropriate for the printer
technology.
Related
I want to get a list of available monitors in Windows 10, same as the monitor list shown in the System display settings (no matter whether they are attached or unattached), just like this:
I use EnumDisplayDevices() to enumerate all displays, but there is no proper flag indicating whether the display is available.
So, how can I do this?
EnumDisplayDevices appears to return pseudo-devices too.
According to EnumDisplayMonitors documentation you can use GetSystemMetrics (SM_CMONITORS) to filter out pseudo devices and receive a list of physical devices only.
Potentially a similar question how to list available monitors in c++ windows 7? helps you too.
EnumDisplayDevices gives you the DISPLAY_DEVICE_ATTACHED_TO_DESKTOP and DISPLAY_DEVICE_MIRRORING_DRIVER flags. MONITORINFOEX gives you the device name to compare with when mapping from HMONITOR.
The QueryDisplayConfig function retrieves information about all possible display paths for all display devices, or views, in the current setting. You can try the document example.
More information.
I want to write a driver to control several aspects of my epson printer: e.g. the position of the printer head, and the other motors involved in moving the paper. The ultimate goal is to be able to build a CNC-type machine out of the printer with minimal/no modification of the printer hardware and without the addition of additional microcontrolers.
I've had this goal for a long time, and am just about to begin reading books on drivers to start this project. Is this goal possible?
(For reference, I am planning to do my project on Linux, using an Epson WorkForce WF-M1030 Monochrome Inkjet Printer...however, I think my question applies more generally to the ability to control printer hardware via computer drivers. )
I'm looking for a method to programatically detect Windows 8 Slate devices using C/C++. My definition of "Slate" is "a portable computing device equipped with a touchscreen but without a dedicated physical keyboard" (so including devices that come with a keyboard dock, but excluding laptops and tradition tablets where the physical keyboard is attached).
I tried using WMI Win32_SystemEnclosure and checking the ChassisTypes, but one Slate reported the ChassisTypes as being "Hand Held" and another reported "Main System Chassis", so this doesn't seem to be reliable.
I'm not able to provide any code, since I don't have a "slate" device to test it on, but I can offer you some suggestions.
You'll probably want to use a heuristic sort of approach, using several API calls to determine the presence or status of various bits of hardware, then determine if the system matches what you're looking for. The GetSystemMetrics API is likely to be the most useful to you; after looking through some documentation, here are the calls that are likely to help you.
GetSystemMetrics with SM_CONVERTIBLESLATEMODE: returns 0 if the system is in Slate Mode and non-zero otherwise. There's no guarantee this will mean the system is an actual slate device, but it can at least tell you if the device has a slate mode and is using it.
GetSystemMetrics with SM_DIGITIZER: returns a bitfield value that tells you whether the system supports touch or a pen. If GetSystemMetrics(SM_DIGITIZER) & TABLET_CONFIG_NONE evaluates to true, your device probably isn't a slate. You can also make good use of the other bitflags this call gives you access to.
GetSystemMetrics with SM_MOUSEPRESENT: tells you whether a mouse is present. This is a very weak test since the docs say virtual mice or sometimes just a mouse port will be enough to set this flag, but it's still worth testing. If a mouse isn't present, your device has a higher chance of being a slate.
GetSystemMetrics with SM_TABLETPC: similar to the SM_DIGITIZER test, this tells you if the Tablet PC Input service is started or not. If the service isn't started, your device probably isn't a tablet.
GetSystemPowerStatus could provide a few useful heuristics as well. This API returns a SYSTEM_POWER_STATUS structure which you can test in the following ways:
If ACLineStatus is 0, your device isn't connected to AC power, so it's more likely to be a slate.
If BatteryFlag is 128, there is no system battery, so your device probably isn't a slate. If it's any other value (except 255, which is unknown status) there is a battery, which means your device is more likely to be a slate.
You can also look into WMI's Win32_Keyboard, in particular its Availability, ConfigManagerErrorCode, and Status properties. At the end of the day there is no way to determine whether keyboard input is from a physical or virtual keyboard, but you can at least attempt to test for a physical keyboard.
Your WMI Win32_SystemEnclosure test would become another heuristic in the list. See what ChassisTypes returns: Desktop, Low Profile Desktop, Mini Tower, Tower, and Laptop probably mean the device isn't a slate. Pizza Box, Portable, Notebook (although generally notebook == laptop in common verbiage, so this will require testing), Hand Held, Space Saving, and Lunch Box are probably more likely to be slates. You can also try to run calculations on the Depth, Height, Width and Weight properties, since anything over a certain size and weight probably won't be a portable device and therefore won't be a slate.
Sample touch detection code from MSDN:
// test for touch
int value = GetSystemMetrics(SM_DIGITIZER);
if (value & NID_READY){ /* stack ready */}
if (value & NID_MULTI_INPUT){
/* digitizer is multitouch */
MessageBoxW(hWnd, L"Multitouch found", L"IsMulti!", MB_OK);
}
if (value & NID_INTEGRATED_TOUCH){ /* Integrated touch */}
I'm not a specialist when it comes to WinAPI, but since noone else answered, maybe it will be of some help to you. On MSDN, there's a list of functions awailable for Windows store apps, which also specifies whether functions can be used on handheld devices. Seems like the Windows.Devices.Enumeration contains exactly what you need - the DeviceInformation class.
All you have to do is list all the devices (there's code one the page which says how to do that), and search the list for a keyboard.
Please note: I don't own any Windows 8 device, so I can't really test if this is helpful or not. Give it a try, and I'll delete my comment if it won't help you out.
I have couple of questions:
What is exactly VJoyD used for? Based on my reading win WDK (Windows Driver Kit) it provides joystick services in Windows (http://msdn.microsoft.com/en-us/library/ff542258(v=vs.85).aspx). If that is the case, can I use it to send commands from my hardware to Vjoyd so my hardware can look like a joystick?
Direct Input is used mostly to read input devices but I want to do the opposite, I would like to write data to direct input so that it becomes availabe in video games, ie. have custom hardware translate information to Direct Input so it is like a joystick.
There's in WDK (dinputd.h), is that what you would use? Any examples would be much helpful, even if it is one-liner to sent input axis value to DInput.
Btw, I am aware of PPJoy but not going to use it because this is for commercial use.
Answering my own questions for the benefit of others:
1.A: VJoyD used by old version of OS to handle joystick input, dead by now.
2.A: In the past, you there were some alternatives but now replaced by HID class.
I've got some bar code scanner devices that can handle a variety of USB interfaces (COMM Emulation, HID Keyboard, HID POS, etc.) The problem is that, while I can tell if the device is in a HID mode, I need to be able to determine if it's HID Keyboard or HID POS.
Is there a way to determine this using Win32 C++, preferably with the built in windows HID library (hidsdi.h)?
You can use HidD_GetHidGuid to get the unique GUID for the device. Device interface guids are defined by each device/application software vendor, Microsoft or third party as they see fit. In some cases the guids are published and public knowledge and are standard interfaces, in some cases they are not.
You can also use the USBView utility from Microsoft which will let you browse the USB tree or you can look in the registry and see if you can find the GUID for your device. You may still have to query your device to determine device type if the config data is not present or it does not reveal itself other than a generic device, if your device supports this.
There are two types of GUIDs: Device Class and Device Interface. A device can only be a part of one class. Unfortunately, the Device Class and Device Interface GUIDs are sometimes the same, thus confusing developers. In the WinXP DDK, standards were created to try and make the definition of GUIDs less confusing.
See also this previous SO question: Use RegisterDeviceNotification() for ALL USB devices.
Here is a list of possible HID Guids: http://msdn.microsoft.com/en-us/library/ms791134.aspx and use HidD_GetHidGuid as Roboto suggested
You'll need to use the HidP_ functions to check the hid report capabilities. Find out what capabilities (usages) are presented by the HIDPOS device, and check if those usages are present using HidD_GetPreparsedData(), HidP_GetCaps() and then HidP_GetValueCaps(and/or ..ButtonCaps, etc). A good place to look for examples is Jan Axelson's page. If the usages are present, then you've got the POS device. If not, then it must be the keyboard (assuming you've confirmed the device is attached.)