|
I have Installed IMapiv2 on my xp service pack2 after reading and downloading from http://support.microsoft.com/kb/KB932716\ link. Still it is not working but IMapiv2 on vista capable of burning dvd. I have checked it.
|
|
|
|
|
Should work using that. Note that XP SP2 is unsupported. Can you try upgrading to SP3?
|
|
|
|
|
It is not working on xp Service pack3 too.
|
|
|
|
|
Have you re-installed the hotfix after upgrading?
If yes, I'm out of options.
|
|
|
|
|
|
I m creating a listview in my existing c++ application.
i m not able to track the mouse click event of the list view header
please help me to come out of this mess..
|
|
|
|
|
|
The wizard of the visual studio will help yoz. "Add event handler" in the contecxt menu of the resource editor.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I'm trying to make packet sniffer for cetain app which uses IOCP sockets by hooking winsock api. Problem is that when i hook(ms detours) WSARecv buffer isn't complete. What api i should hook and how to get complete received buffer?
ty
|
|
|
|
|
Ok, im trying to get data by hooking GetQueuedCompletionStatus. Number of bytes are always correct, but im not sure how to get data. I guess it;s in OverLapped structure ?
thanks!
|
|
|
|
|
I try to embed the window of my program in the desktop.<big>The window is under the desktop icons without covering them!</big>
I have tried the following method.
As far as I know,the desktop consists of four sub-layers.Using spy++,I find the first three layers--1.SysListView32 2.SHELLDLL_DefView 3.Program Manager.
I tried to put my window on top of the second layer.
<pre>BOOL CTestDialogDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// Add "About..." menu item to system menu.
// IDM_ABOUTBOX must be in the system command range.
ASSERT((IDM_ABOUTBOX &amp; 0xFFF0) == IDM_ABOUTBOX);
ASSERT(IDM_ABOUTBOX &lt; 0xF000);
CMenu* pSysMenu = GetSystemMenu(FALSE);
if (pSysMenu != NULL)
{
CString strAboutMenu;
strAboutMenu.LoadString(IDS_ABOUTBOX);
if (!strAboutMenu.IsEmpty())
{
pSysMenu-&gt;AppendMenu(MF_SEPARATOR);
pSysMenu-&gt;AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
}
}
// Set the icon for this dialog. The framework does this automatically
// when the application's main window is not a dialog
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
// TODO: Add extra initialization here
HWND tmpHandle = ::FindWindow("Progman",NULL); //the hwnd of the third layer
tmpHandle = ::GetWindow(tmpHandle,GW_CHILD); //the hwnd of the second layer
CWnd* pWndDesktop = CWnd::FromHandle(tmpHandle); //get the window of the second layer
this->SetParent(pWndDesktop); //set the second layer window as the parent of my window
tmpHandle = ::GetWindow(tmpHandle,GW_CHILD); //the hwnd of the first layer
::SetWindowPos(tmpHandle, HWND_TOPMOST, 0, 0, 0, 0, SWP_SHOWWINDOW|SWP_NOSIZE); //bing the first layer to the top
return TRUE; // return TRUE unless you set the focus to a control
}</pre>
However,this method dosen't work.Does anybody have some guidance on how to do this?
|
|
|
|
|
I can think of 2 things:
1. Use Active Desktop[^], you would somehow activate the "active desktop" feature of windows (don't know if that still exists above 'windows xp' - UPDATE on this: they say under Vista this has been replaced by the Sidebar thing so i guess it is no longer there), set a local HTML page as the source and somehow embed your application into that (thorough a plugin or somesuch).
2. Try to subclass the list view and experiment with handling its WM_PAINT and/or WM_ERASEBKGND messages along with the user input as needed, you probably need to hook into explorer.exe to do this.
A combination of these 2 methods could be to enable Active Desktop, show an empty page and then try to subclass the HTML view that displays the HTML page in the background and then do your own drawing.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Code-o-mat wrote: set a local HTML page as the source and somehow embed your application into that (thorough a plugin or somesuch).
Packaging your C++ application as an ActiveX control would be the logical choice.
Steve
|
|
|
|
|
You should never, ever do this.
If you use the desktop as your parent window, and then display a modal dialog box, you will effectively hang the system.
http://blogs.msdn.com/oldnewthing/archive/2004/02/24/79212.aspx
The window you retrieve from GetDesktopWindow is the parent window of all the windows in the system, and it is not visible, (it is completely covered by it's children). You could try forcing WM_PAINT, after you get a DC through GetDCEx, setting DCX_CLIPCHILDREN to false, but this will result in painting Over the Controls.
Maybe subclass the listview which contains the icons, and do your painting on that one. That should work.
About the Active Desktop solutions mentionned here: Active desktop has been canned with Windows XP 64 bit. Vista and Weven don't carry it anymore. Desktop Gadgets is the flavor of the day.
|
|
|
|
|
Thank you very much for reminding me all these!!!
|
|
|
|
|
WSADATA WS2Info;
if (!WSAStartup(MAKEWORD(2,2), &WS2Info))
{
MessageBox(g_hWindow, L"WinSock2 Initialized", L"Tracing", NULL);
SOCKET IPv4 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (IPv4 != INVALID_SOCKET)
{
MessageBox(g_hWindow, L"Resolving Host", L"Tracing", NULL);
hostent *ResolveHost;
char *HostName = (char *)malloc(MB_CUR_MAX);
wctomb_s( NULL, HostName, MB_CUR_MAX, (wchar_t)Download->HostName);
ResolveHost = gethostbyname(HostName);
if (ResolveHost->h_addr_list[0])
{
MessageBox(g_hWindow, L"Adding Resolved Host to SOCKADDR", L"Tracing", NULL);
SOCKADDR_IN HostService;
HostService.sin_family = AF_INET;
HostService.sin_addr.s_addr = (ULONG)ResolveHost->h_addr_list;
HostService.sin_port = htons(80);
MessageBox(g_hWindow, L"Connecting", L"Tracing", NULL);
if (connect(IPv4, (SOCKADDR*) &HostService, sizeof(HostService)) != SOCKET_ERROR)
{
MessageBox(g_hWindow, L"Connected", L"Tracing", NULL);
}
else
MessageBox(g_hWindow, L"Connection Failed", L"Tracing", NULL);
}
}
else
MessageBox(g_hWindow, L"Socket Creation Failed!", L"Tracing", NULL);
closesocket(IPv4);
}
WSACleanup();
I spent sometime using Network Monitor only to find that HostName resolving isn't returning an accurate IP to the UNICODE use.
char *HostName = (char *)malloc(MB_CUR_MAX);
wctomb_s( NULL, HostName, MB_CUR_MAX, (wchar_t)Download->HostName);
If anyone has any pointers to solving the problem it will be appreciated.
|
|
|
|
|
Fareed Rizkalla wrote: wctomb_s( NULL, HostName, MB_CUR_MAX, (wchar_t)Download->HostName);
This is wrong, wctomb_s() converts a single character, not a string. You should use the wcstombs() function. Your casting of (wchar_t)Download->HostName forces the code to compile but gives you the wrong result.
It's time for a new signature.
|
|
|
|
|
If I can just find the correct magic incantation to shutup the compiler...
Steve
|
|
|
|
|
hostent *ResolveHost;
wchar_t *HosName = L"www.codeproject.com";
MessageBox(g_hWindow, HosName, L"Tracing", NULL);
char *HostName = new char[wcslen(HosName)+1];
wcstombs(HostName, HosName, wcslen(HosName)+1);
wchar_t buf[100];
swprintf(buf, L"Multi-Byte: %s", HostName);
MessageBox(g_hWindow, (LPCWSTR)HostName, L"Tracing", NULL);
ResolveHost = gethostbyname(HostName);
Well I've been using the Network Monitor to see how the resolving is going. The multi byte string has some random conversions in it, because the IP the program is trying to connect to is consistent in the begging and changing in the end.
Casting the best way to shut up a compiler. 
|
|
|
|
|
Hi all
I need to determine at runtime whether the selected printer has color capabilities or not. Microsoft Knowledgebase confirms that there's a problem with using dmColor because under WinNt certain drivers show the wrong value for this member, i-e, they set this value to DMCOLOR_COLOR when actually it's a monochrome printer. The KB, however, doesn't give a solution! Has anyone found a way round this? I'd be thankful for some tips. I've also tried using the DeviceCapabilities function but in vain.
Imran.
[SOLUTION]
The way round is to use NumColors member and if it's 2, the printer's monochrome. Hmmm.
modified on Tuesday, April 20, 2010 8:27 AM
|
|
|
|
|
Hi There.
How to catch exceptions occurred in DLL.
For example
main()
{
try
{
calling the “A.DLL” (DLL(donot know the source code) is generating unhandled exception, access violation)
}
catch(...)
{
//Source Code
}
}
Even if I have catch(...) I am not able to catch the exeption. It says unhandled exeption..... Access violation reading....
How I do catch it in my main program so that I can terminate it properly?
Thanks
-PanB
|
|
|
|
|
See here[^] - always useful to try a Google search first.
It's time for a new signature.
|
|
|
|
|
Thanks Richard. It worked.
I really working hard with Google but when was not able to get any solution, then only came for expert advice.
Thanks anyway. Keep up the good work.
|
|
|
|
|
Perhaps you noticed that I did not give expert advice, but found the answer through Google using the keywords "catch access violation". Really quite simple - give it a try.
It's time for a new signature.
|
|
|
|
|
In general the best thing to do with an access violation in some DLL you don't have source code for is to crash. It's amateurish to think that catching it solves any problems. If you think about it, it's self evident:
- Something went wrong.
- The unexpected event happened part way though a sequence of steps that probably should have been atomic.
I'll give some specific examples of the kind of problems that could occur:
- You were adding a node to a double-linked list when the access violation occurred. Now you have a node that is only partially linked in. Instead of crashing at the point of insertion you crash down the track when iterating over the list.
- The access violation happens after a call to
EnterCriticalSection but before the corresponding LeaveCriticalSection. Instead of crashing at the problem location an entirely different thread now locks up.
- The crash was the last of a series of memory accesses of which some of the earlier ones (that didn't cause a crash) corrupted the heap. You'll now crash at some later time when allocating or freeing memory.
You could come up with a million of these examples. In most cases "recovering" from low-level exceptions by catching them turns a bad problem into a worse one. Sometimes crashing is a feature; don't make things worse trying to "fix" things.
You may already know all this (you did mention something about terminating correctly), but I thought it best to point out just in case. There's also the fact that moving the manifestation of a problem (a crash) even slightly from the source of the problem makes it many times harder to fix in future.
Steve
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
Now with 26% more Twitter