|
Hi,
Is there any article based on the above requirements.
Thanks in advance,
Radhika.
|
|
|
|
|
You dont need to any article you can see MSDN 
|
|
|
|
|
Hi,
I am trying on that.But one more problem what i am having is i am getting an assertion error when i click the particular button to display the directory tree in my tree control.When i click ignore 4 times the tree is displayed in the tree control.I am trying for this since 4 days.Can any one help me on this.
Radhika.
|
|
|
|
|
I think its a new problem and does this error is after remove file/folder?also what error ?
|
|
|
|
|
Hi,
This problem is from the starting.I am trying for this for the past 4 days.It is occuring during the loading of the directory tree into the system drive.When i debug the error is coming at the following line,
if ( m_tree.SubclassDlgItem( IDC_TREE1, this ) )
Radhika.
|
|
|
|
|
SubclassDlgItem subclass your control that created and attach it to CWnd (and a thing did you trace to trace your app and what is it?)
|
|
|
|
|
This is what I like to achieve:
1. Copy the selected text from active window such as notepad
2. Modify the text
3. Send back modified text to the active window and replace the selected text in that window.
step 1 can be achieved by monitor the clipboard while user
copy the selected text into the clipboard. But not sure how to paste back the modified text into that window again.
Any ideas will be appreciated.
www.sqlparser.com
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
