|
Do you want to send a text to notepad?
|
|
|
|
|
|
<br />
ShellExecute(NULL,"open","notepad.exe",NULL,NULL,SW_SHOWNORMAL); <br />
HWND hNoteWnd=::FindWindow("Notepad",NULL); <br />
::SetWindowText(hNoteWnd,"TEST");<br />
|
|
|
|
|
the case of GOLF playing, i want to trace the Golf Ball dynamically. can you please help me to send the path finding Algorithem or any source code?
thanks
arifreza007@yahoo.com
Arif
|
|
|
|
|
What exactly do you want to do? A path finding algorithm will find the shortest path between two points, usually around obstacles or through a maze. This doesn't really apply to a golf ball since it will always go in a straight line.
|
|
|
|
|
There are two c types, one is:
if(...)
{
...
}
else
{
...
}
the other is:
if(...){
...
...
}else{
...
...
}
Witch one do you prefer? And why?
Hi guys. I'm a very man. Do you like fat men?
|
|
|
|
|
We prefer the following because it has got more readability than the other
if(...)
{
...
}
else
{
...
}
Rinu Raj
|
|
|
|
|
Both the ways. It's just upto you what you feel better to work with. IMO the first option offers more readabilty and indentation for your code is also very clear. So I prefer to go with the first option.
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
The first one! Easier on the eyes.
|
|
|
|
|
I've never seen variation 2, although I see a lot of
if {
}
else{
}
Either way, my vote is for 1.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
I prefer the first; it's easier to identify scope with brackets that line up. It also puts some white space between the if (or other leading statements) and code inside the scope. (I also tend to put a blank line before the if.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Hi everybody!
I'm developing an App by MFC , I create a dialog open file from class CFileDialog enable user choose image file to open,and I want default property view in menu views of CFileDialog always is Icon,(default it is List).
Thanks for any help!
|
|
|
|
|
toanmtkh@yahoo.com wrote: create a dialog open file from class CFileDialog enable user choose image file to open,and I want default property view in menu views of CFileDialog always is Icon,(default it is List).
CFileDialog gets its view selection from Explorer. So however Explorer is set to view a director is how CFileDialog should. Quick search of MSDN doesn't revile any hints at modifying the default behavior. However this is code project and someone has already gone through the trouble of modifying CFileDialog for your needs A class based on CFileDialog that provides easy image preview[^]. Good luck 
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
Hi all,
Here is what I'm trying to do. I write a windowless application running in the background. I want to detect every call to CreateWindowEx. Basically, if any other application is trying to create a window that pops up on top of the active window, I want to move it behind the active window, not suppressing it like thouse popup blocker though. I read about it in MSDN and I think I can use SetWindowsHookEx to detect HCBT_CREATEWND. According to the documentation, I need to place the CBTProc function inside a dll. I've followed the steps but it still can't seem to detect HCBT_CREATEWND when other applications create a window. However, it can if the window is created by my own application. Am I missing something?
This is what I have in my application code:
dllModule = LoadLibrary(_T("My.dll"));
if (dllModule)
{
CBTProcPtr = (HOOKPROC) GetProcAddress(dllModule, "CBTProc");
if (CBTProcPtr)
g_hHook = ::SetWindowsHookEx(WH_CBT, CBTProcPtr, dllModule, 0);
}
This is what I have in my dll code:
#include "stdafx.h"
#include <TCHAR.H>
#include "strsafe.h"
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
LRESULT CALLBACK CBTProc(int nCode, WPARAM wParam, LPARAM lParam)
{
TCHAR tempStr[1028] = {0};
_stprintf_s(tempStr, _T("Inside CBTProc. nCode: %d\n"), nCode);
OutputDebugString(tempStr);
if (nCode == HCBT_CREATEWND)
{
OutputDebugString(L"Inside HCBT_CREATEWND\n");
CBT_CREATEWND* wndData = (CBT_CREATEWND*)lParam;
if (wndData && wndData->lpcs)
{
OutputDebugString(wndData->lpcs->lpszName);
OutputDebugString(wndData->lpcs->lpszClass);
}
}
return ::CallNextHookEx(0, nCode, wParam, lParam);
}
|
|
|
|
|
AFAIK, Your process of setting up the hook, Forwarding calls to the window(HOOK) procedure and then releasing the hook should be performed inside the dll. The messages are then captured by the dll before they are passed on to any application.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
Hm... no luck with that either. I added this code to my dll.
void APIENTRY StartHook()
{
if (!gHinstance)
return;
g_hHook = SetWindowsHookEx(WH_CBT, CBTProc, gHinstance, 0);
return;
}
void APIENTRY StopHook()
{
if (g_hHook)
UnhookWindowsHookEx(g_hHook);
}
This to my application
if (dllModule)
{
StartHookProcPtr = (VOIDPROC) GetProcAddress(dllModule, "StartHook");
(StartHookProc)();
}
|
|
|
|
|
When you use global hooks you are effectively writing a distributed application. The calls to OutputDebugString are being called in the context of the application which creates the window ***NOT*** the process which installs the hook - this is the nature of global hooks and why they're so dangerous to overall system stability if written incorrectly. In short, your code may be working but you're looking in the wrong place for the debug messages.
Steve
|
|
|
|
|
You may vote me down but if the calls to OutputDebugString are replaced with calls to something like MessageBeep you may find I'm correct.
Steve
|
|
|
|
|
Replace the calls to OutputDebugString with MessageBeep(-1) and make sure your sound is turned up. Before you do this make sure that MessageBeep(-1) produces an audible beep in a stand-alone program. Do you hear a beep when a window is created in another process?
Steve
|
|
|
|
|
Hi Steve,
Yo Da Man! Yes, it does beep like crazy when I replaced OutputDebugString with MessageBeep.
Thanks so much for the help!
|
|
|
|
|
|
Strange thing. When my hook function is invoked and I try to access the lpszClass value, it will crash the application if it's hooked to its thread id, or visual studio, explorer and everything else (I have to reboot the computer...) if I specify 0 as the thread id in SetWindowsHookEx
I just need to detect if the window class is of a specific name. If I comment out the _tcsstr line the crash will go away, but then I can't detect the specific window. I vaguely remember seeing a bad pointer value in the debugger, but I'm already checking the pointer before using it. Could it be some windows are not initialized properly?
LRESULT CALLBACK CBTProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if (nCode == HCBT_CREATEWND)
{
CBT_CREATEWND* wndData = (CBT_CREATEWND*)lParam;
if (wndData && wndData->lpcs)
{
if (wndData->lpcs->lpszClass)
{
if (_tcsstr(wndData->lpcs->lpszClass, _T("the window class name")))
{
}
}
}
}
return ::CallNextHookEx(0, nCode, wParam, lParam);
}
|
|
|
|
|
jipai wrote: LRESULT CALLBACK CBTProc(int nCode, WPARAM wParam, LPARAM lParam)
have u exported the above function?
nave
|
|
|
|
|
Yup.
LIBRARY "My"
EXPORTS
; Explicit exports can go here
StartHook
StopHook
CBTProc
|
|
|
|
|
See Hooks[^] maybe it is some helpful to you
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
