Why GetClipBoardOwner always returns 0 with acrobat reader ,
When using GetClipBoardOwner with any other MS application for example with Notepad.exe the result will be the real Clipboard Owner , but when using it with Adobe acrobat reader i don't get any result that means 0
i called GetLastError() , it gives a correct handle , but with Adobe acrobat reader it gives 0 as result
Please can some one explains me this ?
many thanks
Something really weird happens with adobe acrobat:
Acrobat uses EmptyClipboard() to taken ownership after it opens the clipboard with NULL (OpenClipboard(NULL)), that means the owner HWND is NULL.
Up to here, everything is okay, the weird thing is that than it uses SetClipboardData() while the owner is NULL, and from MSDN and my own experience, this case should fail the SetClipboardData(), but in case of acrobat the SetClipboardData() does not fail, and places the data in the clipboard, while the owner is NULL!
This is why you get a NULL owner. The new open question is how come SetClipboardData() does not fail...
Related
A OSX app crashes when I try to close a socket handle, it worked fine in all the previous platforms, but it appears to crash in Yosemite.
The line where is crashes is
-(void)stopPacketReceiver
{
close(sd);
}
In Xcode it pauses all the threads and show EXC_GUARD exception, what kind of exception is this, any ideas ?
Thanks,
Ahmed
EDIT:
Here r the exception codes that I get
Exception Type: EXC_GUARD
Exception Codes: 0x4000000100000000, 0x08fd4dbfade2dead
From a post in Apple's old developer forums from Quinn "The Eskimo" (Apple Developer Relations, Developer Technical Support, Core OS/Hardware), edited by me to remove things which were specific to that specific case:
EXC_GUARD is a change in 10.9 designed to help you detect file
descriptor problems. Specifically, the system can now flag specific
file descriptors as being guarded, after which normal operations on
those descriptors will trigger an EXC_GUARD crash (when it wants to
operate on these file descriptors, the system uses special 'guarded'
private APIs).
We added this to the system because we found a lot of apps were
crashing mysteriously after accidentally closing a file descriptor
that had been opened by a system library. For example, if an app
closes the file descriptor used to access the SQLite file backing a
Core Data store, Core Data would then crash mysteriously much later
on. The guard exception gets these problems noticed sooner, and thus
makes them easier to debug.
For an EXC_GUARD crash, the exception codes break down as follows:
o The first exception code … contains three bit
fields:
The top three bits … indicate [the type of guard].
The remainder of the top 32 bits … indicate [which operation was disallowed].
The bottom 32 bits indicate the descriptor in question ….
o The second exception code is a magic number associated with the
guard. …
Your code is closing a socket it doesn't own. Maybe sd contains the descriptor number for a descriptor that you once owned but is now a dangling reference, because you already closed your descriptor and that number has now been reused for somebody else's descriptor. Or maybe sd just has a junk value somehow.
We can decode some more information from the exception codes, but most likely you just have to trace exactly where you're doing with sd over its life.
Update:
From the edited question, I see that you've posted the exception codes. Using the constants from the kernel source, the type of guard is GUARD_TYPE_FD, the operation that was disallowed was kGUARD_EXC_CLOSE (i.e. close()), and the descriptor was 0 (FILENO_STDIN).
So, in all probability, your stopPacketReceiver was called when the sd instance variable was uninitialized and had the default 0 value that all instance variables get when an object is first allocated.
The magic value is 0x08fd4dbfade2dead, which according to the original developer forums post, "indicates that the guard was applied by SQLite". That seems strange. Descriptor 0 would normally be open from process launch (perhaps referencing /dev/null). So, SQLite should not own that.
I suspect what has happened is that your code has actually closed descriptor 0 twice. The first time it was not guarded. It's legal to close FILENO_STDIN. Programs sometimes do it to reopen that descriptor to reference something else (such as /dev/null) if they don't want/need the original standard input. In your case, it would have been an accident but would not have raised an exception. Once it was closed, the descriptor would have been available to be reallocated to the next thing which opened a descriptor. I guess that was SQLite. At that time, SQLite put a guard on the descriptor. Then, your code tried to close it again and got the EXC_GUARD exception.
If I'm right, then it's somewhat random that your code got the exception (although it was always doing something bad). The fact that file descriptor 0 got assigned to a subsystem that applied a guard to it could be a race condition or it could be a change in order of operations between versions of the OS.
You need to be more careful to not close descriptors that you didn't open. You should initialize any instance variable meant to hold a file descriptor to -1, not 0. Likewise, if you close a descriptor that you did own, you should set the instance variable back to -1.
Firstly, that sounds awesome - it sounds like it caught what would have been EXC_BAD_ACCESS (but this is a guess).
My guess is that sd isn't a valid descriptor. It's possible an API changed in Yosemite that's causing the place you create the descriptor to return NULL, or it's possible a change in the event timeline in Yosemite causes it to have already been cleaned up.
Debugging tip here: trace back sd all the way to its creation.
I've always been curious on what nCmdShow means in WinMain of a C program using Windows API.
I looked up the formal explanation: "Controls how the window is to be shown. This parameter can be one of the following values.".
I do not understand what that means, as a Windows program can contain more than one window, or no windows at all. In addition, as program begins, there is no window to be shown to begin with, which makes me question this argument even more.
Also from what I read, it always stays 10, which isn't even on the list of options in "http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559%28v=vs.85%29.aspx"...
Is it obsolete? Can somebody explain its purpose, or provide any references explaining its use? I tried googling but saw nothing.
Thanks!
REVISITED:
When you right click a shortcut and go to properties, there is an option to start the window Minimized, Maximized, or Normal(ly).
Windows provides an nCmdShow to your program in case it wants to act in a special way if it was launched in any of these three ways. For example, it may hide itself inside notification bar if it was requested to be started minimized.
For exhaustiveness:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633548(v=vs.85).aspx describes all the different ways that may be passed.
It is basically a hint to the application how it should show its main window. Although it is legacy, it is not as legacy as the hPrevInstance parameter. But, I digress...
The value of the nCmdShow parameter will be one of the constants specified in ShowWindow's API reference. It can be set by another process or system launching your application via CreateProcess. The STARTUPINFO struct that can optionally be passed to CreateProcess contains a wShowWindow member variable that will get passed to WinMain through the nCmdShow parameter.
Another way the nCmdShow parameter is passed is via calls to ShellExecute.
Off the top of my head, I can't think of any scenario (in recent versions of Windows) in which the operating system will explicitly pass a value other than SW_SHOW when launching an application.
It's not uncommon nor bad for an application to ignore the nCmdShow flag passed to WinMain[?].
Note this section from the ShowWindow documentation:
nCmdShow: This parameter is ignored the first time an application calls ShowWindow, if the program that launched the application provides a STARTUPINFO structure.
Even though your program has no window when it starts, the specified value gets implicitly used the first time you eventually call ShowWindow. (It's not read directly from WinMain's local nCmdShow variable, though, so you can't change its value within WinMain and expect to get different results. In that sense, it's not particularly useful unless your program needs to do something special if it's started minimized or maximized.)
The "n" in nCmdShow means "Short int".
(This is what I wanted to know when I came to this stack overflow page)
Source:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa378932(v=vs.85).aspx
nCmdShow is integer type,this parameter specifies how the application windows should be display( to O.S.)
If no value is specified by you than by default Windows O.S. say SW_NORMAL value of this param.
You can specify values of this parameter , but those who passed to WinMain() only for Windows O.S
I have a problem caused by a failure in Direct3D9::CreateDevice(). It fails when the following code is executed with a locked screen under Windows 7. Due to requirements, I need to be able to create a device while the screen is locked.
I get a D3DERR_INVALIDCALL error when CreateDevice is called with the following parameters. I've experimented extensively with the HWND being used, and double checked that it is valid. I've also tried out various tweaks to the presentation parameters to no avail. Anyone encountered this before or have a better idea of what might be causing the invalid call return?
Again, this failure only occurs with a locked screen, when run in any other tested state, it succeeds.
D3DPRESENT_PARAMETERS pp;
ZeroMemory( &pp, sizeof(D3DPRESENT_PARAMETERS) );
pp.BackBufferFormat = D3DFMT_UNKNOWN;
pp.SwapEffect = D3DSWAPEFFECT_DISCARD;
pp.Windowed = TRUE;
HWND focusWndHnd = GetConsoleWindow();
if ( focusWndHnd == NULL && pp.hDeviceWindow == NULL )
{
focusWndHnd = ::GetDesktopWindow();
}
IDirect3DDevice9* pd3dDevice;
IDirect3D9* pD3D = Direct3DCreate9( D3D_SDK_VERSION );
hr = pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_NULLREF, focusWndHnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING|D3DCREATE_FPU_PRESERVE, &pp, &pd3dDevice );
The legacy Direct3D 9 interface considers the 'secure desktop' to be a lost device scenario. Use of a WDDM aware version of Direct3D (Direct3D9Ex, Direct3D 10.x, or Direct3D 11.x) will avoid this problem.
Could it be that you need a different value for BackBufferFormat different than D3DFMT_UNKNOWN, due to only windowed apps allowing that value, just like OJ stated here?
My memory is hazy, but I believe this is a known limitation ("by design") with D3D with respect to the lock screen (and running as a service).
Even if you could create the D3D device, you won't be able to draw on top of the lock screen. So you'll probably be better off designing your app such that it defers the D3D device creation until after the screen becomes unlocked.
Use WTSRegisterSessionNotification to register for notifications of when the screen becomes locked or unlocked.
Thanks to Chuck Walbourn's answer I have solved my related issue that the D3D Device initialization fails as soon the elevation prompt secure session is active. In my case I received a D3DERR_NOTAVAILABLE error during the secure session. Having replaced IDirect3D9* with IDirect3D9Ex* and Direct3DCreate9 with Direct3DCreate9Ex then initialization finished successfully!
Additionally I have to stress that Chuck's answer does not refer to Kent's answer directly but just to a related issue, since - as I have understood it right - Kent's scenario refers to the WTS_SESSIONSTATE_LOCK session that can be entered through CTRL+L. In Kent's case I haven't experienced a problem with the D3D initialization in a locked session.
I'm trying to register a performance counter and part of this process includes adding some textual descriptions to a specific registry key. For English this key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009 which apparently is also known as HKEY_PERFORMANCE_TEXT. There are a pair of values under there (Counter, Help) that have REG_MULTI_SZ data, and I need to modify them to accomplish my goal.
The official way of doing this is by using a tool called lodctr along with a .h and .ini file. There is also a function for doing this programmatically, but my understanding is that it is just a simple wrapper around calling the lodctr program. I found the prospect of maintaining, distributing, and keeping synchronized 3 separate files a bit cumbersome, so I previously wrote code to do this and it worked fine under Windows XP (and possibly Vista, though I don't remember for sure).
Now I'm trying to use the same code on Windows 7 and it doesn't work. The problem is that whenever I try to set the registry values it fails with ERROR_BADKEY; even regedit fails to modify the values, so it's not a problem with my code. I ran Process Monitor against it and noticed that there was no activity at the driver level, so it seems this access must be getting blocked in user-mode code (e.g. advapi32.dll or wherever). I understand why Microsoft would try to prevent people from doing this as it is very easy to screw up, and doing so will screw up the entire performance counter collection on the machine.
I'm going to debug lodctr and see what the magic is purely out of curiosity, but I'm wondering if anybody has run into this before? Are there any alternatives other than the lodctr utility? Perhaps calling the NT registry API directly? I would really prefer to avoid the hassle of the lodctr method if possible.
A minimal example to reproduce the issue:
HKEY hKey = NULL;
LONG nResult = RegOpenKeyEx(HKEY_LOCAL_MACHINE, _T("SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\009"), 0, KEY_ALL_ACCESS, &hKey);
if(ERROR_SUCCESS == nResult)
{
LPCTSTR lpData = _T("bar");
DWORD cbData = (_tcsclen(lpData) + 1) * sizeof(TCHAR);
nResult = RegSetValueEx(hKey, _T("foo"), 0, REG_SZ, (const BYTE*)lpData, cbData);
// here nResult == ERROR_BADKEY
RegCloseKey(hKey);
hKey = NULL;
}
EDIT 1:
I spent about an hour or so trying to debug the official APIs and couldn't figure it out so I tried some more Google. After a while I came across this KB article which explains the RegSetValueEx behavior. Since it mentioned modifying system files that got me to thinking that perhaps this particular registry data is backed by a mapped file. Then I came across another KB article that mentions Perfc009.dat and Perfh009.dat in the system32 folder. Opened these up in a hex editor and sure enough it is the raw REG_MULTI_SZ data I am trying to modify. Now that I know that maybe I can take another look and figure it out, though I am bored with it for now.
Never mind, I give up. It's easier to just go with the flow. Instead of trying to modify the registry directly, I will create the .h and .ini files programmatically and invoke the relevant functions.
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.