|
LuisFilipeSa wrote: BitBlt(thisDC, rc.left, rc.top, rc.right-rc.left, rc.bottom-rc.top, hdcMem, 0, 0,SRCCOPY);
It looks like (BTW your code appears a bit involute...) you're bit-blitting in the wrong direction, i.e. memory->screen instead of screen->memory.
Please, use the code block button for posting code snippets.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Yes but when bit-blitting in that direction it works fine, this is, the final bitmap is displayed properly on the screen. But when I try to copy that bitmap to a bitmap file it does not work.
That piece of code that you copied on your reply is working fine, this is:
BitBlt(thisDC, rc.left, rc.top, rc.right-rc.left, rc.bottom-rc.top, hdcMem, 0, 0,SRCCOPY);
The problem is within the code in bold that I posted before.
The rest of the code which is not in bold works perfectly.
Any more advice please?
Thank you.
|
|
|
|
|
You need to blit into the opposite direction if you wish to save correctly the bitmap content into the array.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I do understand now what you are saying, but i am a bit lost, don't know what to do next.
So I have blitted into "thisDC" variable according to my code, then next I have:
CreateDIBSection(hdcMem, &info, DIB_RGB_COLORS, (void**)memory, 0, 0);
Then I thought that by doing the above code everything would go to "memory" variable.
What should I do next? Can you give me an example or help me out please.
Thank you.
|
|
|
|
|
I'm updating an OleDb application. I didn't write the original logic however it closely resembles the OleDb samples provided by Microsoft. It uses the standard IDBInitialize, IDBCreateSession, IDBCreateCommand and ICommandText interfaces to call a stored procedure, returning an IRowset instance. The ICommandWithParams interface is used to set parameter information for the stored procedures and IID_IAccessor to create bindings for the buffer to hold the returned data. ie. fairly standard OleDb code, as noted virtually identical to the samples provided by Microsoft. It works well and has done for a while. Currently the Rowsets are all forward only. All the update requires is that the Rowsets support being able to scroll through the data more than once. According to the documentation this is done by creating an instance of the ICommandProperties interface, filling some DBPROP structures and calling ICommandProperties::SetProperties. However when I do this I get an error on ICommandText::Execute. If I subsequently call ICommandProperties::GetProperties with the guidPropertySet of an DBPROPIDSET struct set to DBPROPSET_PROPERTIESINERROR it tells me that the properties I've set are invalid. This happened regardless of the properties I attempted to set. Out of curiosity I created a test application that ran a select command rather than calling a stored procedure. This ran perfectly. When I switched the logic so that it called a parameter-less stored procedure that returned the exact same data I got the errors again, suggesting that there is something different you need to do for stored procedures. However this is old technology now and I can't find any information (as well as being something of an OleDb noob!)
Any help much appreciated.
|
|
|
|
|
Hi,
I created a tracking tooltip which works fine on Windows XP without a manifest, the tooltip is using TTF_TRACK and TTF_TRANSPARENT tooltip flags. When I add a manifest the left mouse click still works as expected (control behind tooltip receives WM_LBUTTONDOWN ), but a double-click will not work (control behind the tooltip receives no WM_LBUTTONDBLCLK ). Also the dialog loses focus when double-clicking over the tooltip, I am guessing that the tooltip gets the focus.
I needed some time to rule out any other cause for this problem, confirmed that nobody else is stealing messages, it's just triggered by using a manifest in order to get XP Visual styles[^]. It looks like the tooltip implementation in ComCtl32.dll Version 6 is different and double-click mouse events are not forwarded to the parent window. Anyone has an idea how to fix this problem? Thanks!
Here is my code to create the tooltip:
m_hTooltip = ::CreateWindowEx(WS_EX_TOPMOST, TOOLTIPS_CLASS, NULL,
WS_POPUP | TTS_NOPREFIX | TTS_ALWAYSTIP,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
m_hWnd, NULL, NULL, NULL);
if(m_hTooltip)
{
TOOLINFO ti;
memset(&ti, 0, sizeof(ti));
ti.cbSize = sizeof(ti);
ti.uFlags = TTF_TRACK | TTF_ABSOLUTE | TTF_TRANSPARENT | TTF_IDISHWND;
ti.hwnd = m_hWnd;
ti.uId = (UINT)m_hTooltip;
::SendMessage(m_hTooltip, TTM_ADDTOOL, 0, (LPARAM)&ti);
}
And then later to enable/disable the tooltip:
if(bEnable)
{
ti.lpszText = (LPTSTR)pText;
::SendMessage(m_hTooltip, TTM_UPDATETIPTEXT, 0, (LPARAM) &ti);
::SendMessage(m_hTooltip, TTM_TRACKPOSITION, 0, (LPARAM) MAKELONG(pRect->left, pRect->top));
::SendMessage(m_hTooltip, TTM_TRACKACTIVATE, TRUE, (LPARAM)&ti);
} else {
::SendMessage(m_hTooltip, TTM_TRACKACTIVATE, FALSE, (LPARAM)&ti);
}
|
|
|
|
|
Subclassing the tooltip control fixed the problem on Windows XP, found no other solution to get the transparency functionality with ComCtl32.dll version 6. Now it works both with or without manifest.
|
|
|
|
|
Hello people!
I wrote a little test application to experiment with GetThreadContext[^]. In this application, which is actually a dialog based application, i have 3 threads, the GUI thread, a thread that runs a few pointless loops and one that regularry enumerates the threads belonging to this process and calls GetThreadContext on each thread. In the enumeration i use CreateToolhelp32Snapshot[^] method and Thread32First[^]/Thread32Next[^] to get the thread IDs, then i use OpenThread[^] specifying the flag THREAD_GET_CONTEXT to gain the handle of the thread and then i feed GetThreadContext with this handle. In the CONTEXT struct i get the info in i give CONTEXT_CONTROL for the ContextFlags member, as found in winnt.h , to get the program counter (that's Eip , right?). And here comes the part i do not understand and require some help with. For each thread i am getting a different value in the Eip, that is understandable, since the 3 threads are executing different parts of the code, however, this value never seems to be changing in time, what i mean is, if i run my program and for a given thread i get -let's say- 12345678 for Eip, it will still be 12345678 in 10 secs, 15 secs, 1 minutes, it never seems to change. What i would expect is that this value keeps changing as the thread runs and executes different parts of the code. Btw all the rest of the registers i get if i specify CONTEXT_CONTROL behaves the same way. Can anyone explain me why and maybe give me a hint how i could actually get the program counter the correct way for the threads? (The point of this all is that i just want to see if i can detect deadlocked threads this way or not.)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
I had an idea:
The values are only saved when the threads are switched, maybe the granularity is so big that it just doesn't switch often enough?
But that really wouldn't make sense, context switches happen often..
On an other note though, you can't reliably detect deadlocks this way unless you're allowed to make some assumptions about the code. For example if it's possible to get to the same address more than once (eg a loop) then you may be lucky enough to always catch it there (and it may really happen, if there is a place where it will always wait a while there is a pretty good chance that you'll catch it there), the chance that it could happen makes it unreliable.
And if it stays at a given address for a while, how long until you will declare it dead? What if it's just slow?
Actual detection is possible by constructing a wait-for graph.
note: I probably make mistakes instead of sense, I apologize in advance
|
|
|
|
|
I know that detecting endless loops can't be done this way (easily) but i was hoping that if a thread is sitting on a WaitForSingleObject or WaitForMultipleObjects call for example then its IP doesn't change much, true that i could get into a situation where the given thread isn't deadlocked, just runs into the same place quite often and it might happen that the "watcher thread" always finds it sitting there and will think it is dead...but all this is just an experiment for now to see what is possible and what is not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Ok well then I can't help too much, I don't know why the values aren't updated more often, there is probably some arcane windows-specific reason that I'm not aware of
|
|
|
|
|
Thanks anyways
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Hi,
My project involves receiving input from a keyboard device. I use "Raw Input" to collect data only from that device. But I also wish other applications NOT to receive data from that device. Anybody can help me?
Thanks in advance
|
|
|
|
|
I am getting an Illegal Indirection Error on this code, and I am not quite sure what I am doing wrong.
http://msdn.microsoft.com/en-us/libr...65(VS.85).aspx
That link shows the function and what it should do. Am I on the right track? What do I have to do to fix the error.
#include <iostream>
#include "windows.h"
#include "Wincrypt.h"
int main()
{
PCCERT_CHAIN_CONTEXT chainContext;
HCERTSTORE certStore = "MY";
DWORD dwCertEncodingType = X509_ASN_ENCODING;
DWORD dwFindFlags = CERT_CHAIN_FIND_BY_ISSUER_NO_KEY_FLAG;
DWORD dwFindType = CERT_CHAIN_FIND_BY_ISSUER;
const void *pvFindPara = "MyIssuer";
PCCERT_CHAIN_CONTEXT pPrevChainContext = NULL;
while (chainContext = CertFindChainInStore(certStore,
dwCertEncodingType,
dwFindFlags,
dwFindType,
*pvFindPara,
pPrevChainContext))
{
printf((const char*)chainContext);
}
system("PAUSE");
return 0;
}
|
|
|
|
|
mypicturefaded wrote: *pvFindPara, //This line contains the error.
It should be pvFindPara and not *pvFindPara . Additionally, you should link to Crypt32.lib . Just add this code after including all the header files: #pragma comment(lib, "Crypt32")
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Well, it complies now! But it is not return any results. I am entering the Issuer correctly...
Is there something in my syntax that isn't correct?
|
|
|
|
|
I have no idea what are you trying to achieve. There is no link in your previous post (the URL is incomplete). To add to it, system("PAUSE"); is a horrible thing to do.
mypicturefaded wrote: Is there something in my syntax that isn't correct?
If there's a syntax error, your code won't compile.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: There is no link in your previous post (the URL is incomplete).
Probably this one.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I am aware that it is a horrible thing to do.
But for this example I highly doubt it is messing with anything I am doing.
I need to be able to get the Certificate Chain so I can plug it into an Adobe app.
I don't know why you feel the need to pick apart my wording.
The code complies, and runs, but I am not getting the expected results.
The while loop is failing and going to the end of the program. So it isn't picking up the certificates.
#include <iostream>
#include "windows.h"
#include "Wincrypt.h"
#pragma comment(lib, "Crypt32")
int main()
{
PCCERT_CHAIN_CONTEXT chainContext;
HCERTSTORE certStore = "MY";
DWORD dwCertEncodingType = X509_ASN_ENCODING;
DWORD dwFindFlags = CERT_CHAIN_FIND_BY_ISSUER_NO_KEY_FLAG;
DWORD dwFindType = CERT_CHAIN_FIND_BY_ISSUER;
const void *pvFindPara = "MyIssuer";
PCCERT_CHAIN_CONTEXT pPrevChainContext = NULL;
while (chainContext = CertFindChainInStore(certStore,
dwCertEncodingType,
dwFindFlags,
dwFindType,
pvFindPara,
pPrevChainContext))
{
printf((const char*)chainContext);
}
system("PAUSE");
return 0;
}
Yes David you are right, that is the correct link.
|
|
|
|
|
mypicturefaded wrote: I need to be able to get the Certificate Chain so I can plug it into an Adobe app.
Have you seen this?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
That IS the first time I have seen that. It still doesn't iterate through any on my certificates though.
I really am a little confused...Every example I have tried to implement fails at the while loop.
|
|
|
|
|
mypicturefaded,
The code you have shown is looking for certificates in the certificate store named "MY" signed by "MyIssuer". Are you sure that you have certificates that match this criteria?
You can check by following the instrustions below.
How to: View Certificates with the MMC Snap-in[^]
You should also note that the default certificate chain is HCCE_CURRENT_USER. If you need to enumerate certificates in the local system account you will need to use the CertGetCertificateChain Function[^] with the hChainEngine argument set as HCCE_LOCAL_MACHINE.
Best Wishes,
-David Delaune
|
|
|
|
|
In a function OnSysCommand() check a parameter for equality SC_MAXIMIZE. Then wrote a code which works perfectly in OnSizing(), but GetWindowRect() and ScreenToClient() return the rectangle of that window which was to maximization. What is a problem in?
|
|
|
|
|
What are you trying to do here?
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
zhenek91 wrote: but GetWindowRect() and ScreenToClient() return the rectangle of that window which was to maximization
do you want ScreenToClient Information in maximize mode or before maximize
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|