I am using WIA2.0 on VB6.
I could do scanning without anyissues..
But, the problem is i could not figure out the number of pages scanned when it's ADF.
I could see something like this in msdn.
WIA_DPS_ENDORSER_STRING with a token as
$PAGE_COUNT$ The number of pages transferred.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms630195(v=vs.85).aspx
But, i don't know how to access this in VB6.
Any help would be appriciated.
Thanks.
-Dinakaran.AS
As far as I can tell this count is probably strictly local to the scanner itself when it has an endorser printer. It may even be a "hardware" counter much like photocopier counters. It probably can only be reset using a physical key or administrative password at the scanner to unlock and reset it. Looks as if it is meant for auditing purposes.
WIA_DPS_ENDORSER_CHARACTERS (ScannerDeviceEndorserCharacters)
Contains all the valid characters that an application can use to
create valid endorser strings. An endorser is a printer installed on a
scanner that imprints a text message on every page scanned. The
minidriver should validate the setting of the WIA_DPS_ENDORSER_STRING
property against the valid character set in this property. The
minidriver creates and maintains this property.
WIA_DPS_ENDORSER_STRING (ScannerDeviceEndorserString)
Contains a string that is to be endorsed (in other words, printed) on
each page that the minidriver scans. An application sets this property
using the valid character set that is reported in the
WIA_DPS_ENDORSER_CHARACTERS property. The minidriver should endorse
documents only if a string is set in this property. An empty string
means that the endorser functionality is disabled.
Then we have:
WIA_IPS_PAGES (ScannerPicturePages)
Note: This property is supported only by Windows Vista and later.
Contains the current number of pages to be acquired from an automatic
document feeder. The minidriver creates and maintains this property.
Type: VT_I4; Access: Read/Write; Valid values: WIA_PROP_RANGE This is
zero through the maximum number of pages that the scanner can scan.
The value is ALL_PAGES (= 0) if the scanner can scan continuously.
An application reads this property to determine the document feeder's
page capacity. The application also sets this property to the number
of pages it is going to scan.
Related
The Debug API reports DLL load events through a LOAD_DLL_DEBUG_INFO event. One of the structure's data members optionally holds the DLL's file name (lpImageName).
The character encoding of this field is described as:
If fUnicode is a nonzero value, the name string is Unicode; otherwise, it is ANSI.
Unicode presumably means UTF-16. Though it's unclear which codepage to use to interpret the ANSI encoding. There are multiple potential contenders (e.g. the originating process' default codepage, the system's codepage, the receiving process' default codepage, the receiving thread's current codepage, etc.).
Which codepage is it?
initially the debug event comes in the form DBGUI_WAIT_STATE_CHANGE
if use WaitForDebugEvent[Ex] api - it internally convert DBGUI_WAIT_STATE_CHANGE to DEBUG_EVENT by using DbgUiConvertStateChangeStructure[Ex]
when section (file mapping in win32 terms) created with SEC_IMAGE mapped in process, which is being debugged, the DbgLoadDllStateChange message send to debugger. DbgUiConvertStateChangeStructure[Ex] convert it to LOAD_DLL_DEBUG_INFO
note that original DBGKM_LOAD_DLL not containing any info about are in ansi or unicode was NamePointer. this is "unknown". the DbgUiConvertStateChangeStructure[Ex] always hard-code fUnicode = TRUE. this string, if exist, always in unicode.
This member is strictly optional. Debuggers must be prepared to handle
the case where lpImageName is NULL or *lpImageName (in the address
space of the process being debugged) is NULL. Specifically, the system
will never provide an image name for a create process event, and it
will not likely pass an image name for the first DLL event. The system
will also never provide this information in the case of debugging
events that originate from a call to the DebugActiveProcess function.
note, that lpImageName is pointer to pointer of a string (WCHAR** lpImageName can be say). in current implementation - this is always point to NT_TIB.ArbitraryUserPointer (not containing value of ArbitraryUserPointer but address of ArbitraryUserPointer)
formally can say lpImageName = &ptib->ArbitraryUserPointer where NT_TIB* ptib.
so lpImageName by self never 0, but *lpImageName (of course in target process address space) can be 0. when LdrLoadDll (or LoadLibrary) load dll, before map image section (call to ZwMapViewOfSection) set ArbitraryUserPointer to unicode string passed to LdrLoadDll as is. and restore original value of ArbitraryUserPointer after this. in case image name for a create process event, and image name for the first DLL (ntdll) here (in ArbitraryUserPointer 0) also it of course not valid when we receive debug events latter (case of DebugActiveProcess). so use lpImageName not reliable.
also interesing that in case load and unload image section (this is not always mean dll load/unload) (dwProcessId, dwThreadId) not of process/thread in which the debugging event occurred, but process/thread which call ZwMapViewOfSection or ZwUnmapViewOfSection. this is in general case different things, because possible map/unmap section in another process. however this is rarely case, but many debuggers (including windbg and from msvc) wrong handle this case and hung on it
Reading the following documentation:
https://learn.microsoft.com/en-us/windows/desktop/api/winuser/ns-winuser-tagkbdllhookstruct
The bit 4 (counting from 0), is defined as - "Specifies whether the event was injected. The value is 1 if that is the case; otherwise, it is 0. Note that bit 1 is not necessarily set when bit 4 is set."
What is the actual definition of "injected event?" in this context?
You'd think it was an easier thing to google.
If you look at Microsoft's documentation for the SendInput function it describes what it does as inserting or injecting input:
"The function returns the number of events that it successfully inserted into the keyboard or mouse input stream. .... This function is subject to UIPI. Applications are permitted to inject input only into applications that are at an equal or lesser integrity level."
Keyboard input generated by the user and sent from the device driver will not have the bit set. Input created using API functions will have the bit set.
According to
AudioHardware.h
kAudioHardwarePropertyTranslateUIDToDevice
This property fetches the AudioObjectID that corresponds to the AudioDevice that has the given UID. The UID is passed in via the qualifier as a CFString while the AudioObjectID for the AudioDevice is returned to the caller as the property's data. Note that an error is not returned if the UID doesn't refer to any AudioDevices. Rather, this property will return kAudioObjectUnknown as the value of the property.
I wonder what is the user case for this property?
actually I also have question about
kAudioHardwarePropertyPlugInList
kAudioHardwarePropertyTranslateBundleIDToPlugIn
I wonder if where we could find more detailed reference about these properties?
This is for when you need to store, such as in preferences, which device is used or selected for a particular purpose and then find that device on some subsequent run. It is the complement to:
#constant kAudioDevicePropertyDeviceUID
A CFString that contains a persistent identifier for the AudioDevice. An
AudioDevice's UID is persistent across boots. The content of the UID string
is a black box and may contain information that is unique to a particular
instance of an AudioDevice's hardware or unique to the CPU. Therefore they
are not suitable for passing between CPUs or for identifying similar models
of hardware. The caller is responsible for releasing the returned CFObject.
So, you would fetch the device's UID and store that in your preferences or document. Then, on a subsequent run or when that document is opened, you can use kAudioHardwarePropertyTranslateUIDToDevice to look up the AudioDevice object from that UID.
The docs for the SetupDiSetDeviceRegistryProperty function say,
The following values are reserved for use by the operating system and
cannot be used in the Property parameter ...
SPDRP_HARDWAREID
However, there are lots of examples of code out there, including MS DevCon utility which uses this function with the SPDRP_HARDWAREID parameter, ie:
SetupDiSetDeviceRegistryProperty(DeviceInfoSet,
&DeviceInfoData,
SPDRP_HARDWAREID,
(LPBYTE)hwIdList,
(lstrlen(hwIdList)+1+1)*sizeof(TCHAR)))
They also have an article which suggests doing so:
If an installer detects a non-PnP device, the installer should select a driver for the device as follows: create a device information element (SetupDiCreateDeviceInfo), set the SPDRP_HARDWAREID property by calling SetupDiSetDeviceRegistryProperty
I'd like to (and do) use this function to set Hardware ID for my virtual device. The question is - is it a typo in the manual, or it's some sort of unsupported behavior and therefore it can stop working any time?
TL;DR: If you're creating a root-enumerated device node, you're free to set SPDRP_HARDWAREID/SPDRP_COMPATIBLEIDS yourself by calling SetupDiSetDeviceRegistryProperty. Otherwise you're not allowed to do so.
This was an error in the docs that was fixed at some point.
Today the docs of SetupDiSetDeviceRegistryProperty read:
SPDRP_HARDWAREID or SPDRP_COMPATIBLEIDS can only be used when DeviceInfoData represents a root-enumerated device. For other devices, the bus driver reports hardware and compatible IDs when enumerating a child device after receiving IRP_MN_QUERY_ID. [Emphasis mine]
... which is exactly what DevCon does.
i need to tell a printer driver to issue a form feed.
i'm printing directly to a printer using the:
OpenPrinter
StartDocPrinter
StartPagePrinter
WritePrinter
EndPagePrinter
EndDocPrinter
ClosePrinter
set of API calls.
A lot of the inspiration came from KB138594 - HOWTO: Send Raw Data to a Printer by Using the Win32 API. An important point to note in that KB article is that they (and my copied code) start the document in RAW mode:
// Fill in the structure with info about this "document."
docInfo.pDocName = "My Document";
docInfo.pOutputFile = NULL;
docInfo.pDatatype = "RAW";
StartDocPrinter(hPrinter, 1, docInfo);
Note: RAW mode (as opposed to TEXT mode) means we are issuing raw bytes to the printer driver. We promise to talk in the language it understands.
We can then use WritePrinter to write everything we want:
WritePrinter(hPrinter, "Hello, world!"); //note, extra parameters removed for clarity
WritePrinter(hPrinter, 0x0c); //form-feed
The problem here is the 0x0c form-feed character. Because we've opened the printer in RAW mode, we are promising we will send the printer driver bytes it can process. The drivers of most printers take 0x0C to mean you want to issue a form-feed.
The problem is that other printers (PDF printer, Microsoft XPS Printers) expect RAW print jobs to be in their own printer language. If you use the above to print to an XPS or PDF printer: nothing happens (i.e. no save dialog, nothing printed).
i asked for a solution to this question a while ago, and a response was that you have to change the document mode from RAW:
docInfo.pDatatype = "RAW";
to TEXT:
docInfo.pDataType = "TEXT";
Well this probably is because you send
"RAW" data directly to the printer,
and RAW can be any PDL. But the XPS
driver will probably only understands
XPS, and it will probably just ignore
your "unknown: Hello, world!0xFF" PDL. The
XPS driver will probably, if any, only
accept XPS data when you write
directly to it.
If you want to render text on the XPS
driver, you should use GDI. You might
be able to send plain text to the
driver if you specify "TEXT" as the
datatype. The print processor attached
to the driver will then "convert" the
plaintext for you by rendering the job
via GDI to the driver.
So that worked, i changed my code to declare the print document as TEXT:
// Fill in the structure with info about this "document."
docInfo.pDocName = "My Document";
docInfo.pOutputFile = NULL;
docInfo.pDatatype = "TEXT";
StartDocPrinter(hPrinter, 1, docInfo);
WritePrinter(hPrinter, "Hello, world!");
WritePrinter(hPrinter, 0x0c); //form-feed
And then the Save As dialog for XPS and PDF printers appear, and it saves correctly. And i thought all was fixed.
Except months later, when i tried to print to a <quote>real</quote> printer: the form-feed doesn't happen - presumably because i am no longer printing in "raw printer commands" mode.
So what i need is the Windows-ish way of issuing a form feed. i need the API call that will tell printer driver that i want the printer to perform a form-feed.
My question: How to tell a printer to issue a Form-Feed during printing?
Background on Data Types
The print processor tells the spooler to alter a job according to the document data type. It works in conjunction with the printer driver to send the spooled print jobs from the hard drive to the printer.
Software vendors occasionally develop their own print processors to support custom data types. Normally, the print processor does not require any settings or intervention from administrators.
Data types
The Windows printing process normally supports five data types. The two most commonly used data types, enhanced metafile (EMF) and ready to print (RAW), affect performance in different ways on both the client computer and the print server computer.
RAW is the default data type for clients other than Windows-based programs. The RAW data type tells the spooler not to alter the print job at all prior to printing. With this data type, the entire process of preparing the print job is done on the client computer.
EMF, or enhanced metafile, is the default datatype with most Windows-based programs. With EMF, the printed document is altered into a metafile format that is more portable than RAW files and usually can be printed on any printer. EMF files tend to be smaller than RAW files that contain the same print job. Regarding performance, only the first portion of a print job is altered, or rendered on the client computer, but most of the impact is on the print server computer, which also helps the application on the client computer to return control to the user faster.
The following table (taken from MSDN) shows the five different data types supported by the default Windows print processor:
Data type: RAW
Directions to spooler: Print the document with no changes.
Use: This is the data type for all clients not based on Windows.
Data type: RAW [FF appended]
Directions to spooler: Append a form-feed character (0x0C), but make no other changes. (A PCL printer omits the document's last page if there is no trailing form-feed.)
Use: Required for some applications. Windows does not assign it, but it can be set as the default in the Print Processor dialog box.
Data type: RAW [FF auto]
Directions to spooler: Check for a trailing form-feed and add one if it is not already there, but make no other changes.
Use: Required for some applications. Windows does not assign it, but it can be set as the default in the Print Processor dialog box.
Data type: NT EMF 1.00x
Directions to spooler: Treat the document as an enhanced metafile (EMF) rather than the RAW data that the printer driver puts out.
Use: EMF documents are created by Windows.
Data type: TEXT
Directions to spooler: Treat the entire job as ANSI text and add print specifications using the print device's factory defaults.
Use: This is useful when the print job is simple text and the target print device cannot interpret simple text.
You can see the print processors available for a printer, and the data types that each processor supports, through the properties of a printer in the control panel:
See also
Send ESC commands to a printer in C#
Feed paper on POS Printer C#
Print raw data to a thermal-printer using .NET
Yeah, that doesn't work. You are intentionally bypassing the printer driver, the chunk of code that presents a universal interface to any printer. Which leaves you to deal with the peculiarities of each specific printer model.
There are some common interfaces, the one you used in your code is the one that dot matrix printers of old used. PCL is common on Hewlett Packard laser printers. Postscript is common on high-end printers. The latter two have their own incantations to get a form feed.
Then there's the ocean of cheap laser and ink jet printers. They often don't have a well defined interface at all. Instead of having a processor inside the printer that translates printer commands to dots on paper, they let the printer driver do all the hard work. You'll never get one of those going, the interface is proprietary and undocumented.
The printer driver is your friend here. PrintDocument the class to use it. Getting a form feed is easy, just set e.HasMorePages = true and exit the PrintPage event handler. You already saw the StreamPrinter class I linked.
I'm unfamiliar with the TEXT document type, but I presume it's just a lowest common denominator "dumb printer" representation. If so, it might recognize a form-feed character, except you've been using the wrong character - it's not 0x12 or 0xFF, it's 0x0c. See http://en.wikipedia.org/wiki/Ascii
Since my last answer was no help, lets try the obvious. Have you tried doing EndPagePrinter followed by StartPagePrinter whenever you need a page break?
If that still doesn't work you may need to do it the hard way, using GDI. The stack looks just slightly different from the one you're using:
CreateDC
CreateFont
SelectObject
StartDoc
StartPage
TextOut
EndPage
EndDoc
DeleteDC
You'll be required to manage a font and place the text on the page yourself at each line position.