|
hi.
my english is very bad.
but you can colse the project .then delete all files with extension aps.clw.
ncb.opt and dsw.then cilked on file dsp .press ok.and from build menu cliked on the rebuild all.
then open class wizard prees ok  and cliked on the AddAll Button.
you can see all class in the workspace.
|
|
|
|
|
hi.
my english is very bad.
but you can colse the project .then delete all files with extension aps.clw.
ncb.opt and dsw.then cilked on file dsp .press ok.and from build menu cliked on the rebuild all.
then open class wizard and cliked on the AddAll Button.
you can see all class in the workspace.
|
|
|
|
|
thank you all for the help.
It works !!!
|
|
|
|
|
i.e.
if user selects a directory and/or file (or multiple selections) in Windows explorer, i need to know these user selections when user clicks a button in my app - knowing selection by a click (WM_message), not monitor Exploere.
thanks
includeh10
|
|
|
|
|
I'm a bit confused. What does Windows Explorer have to do with your app's response to a button-click?
Are you simply wanting to know what selection has been made within Windows Explorer? I'm not for sure, but I think that IPropertyNotifySink might be needed for this.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
maybe my english is not good enough to ...
they are 2 things: just think about the app needs to know user selections by a button-click ---- button-click is not the same as monitoring all Explorer (use less CPU time?).
cheers
includeh10
|
|
|
|
|
i simply checked IPropertyNotifySink - the function received notifications of changes (or monitor changes from my app's view), it is not my need.
includeh10
|
|
|
|
|
If you want to query Windows Explorer yourself rather than have it notify you, you could use something like:
HWND hWnd = FindWindow("ExploreWClass", NULL);
if (NULL != hWnd)
hWnd = FindWindowEx(hWnd, NULL, "SHELLDLL_DefView", NULL);
if (NULL != hWnd)
hWnd = FindWindowEx(hWnd, NULL, "SysListView32", NULL);
if (NULL != hWnd)
{
CListView *p = (CListView *) CListView::FromHandle(hWnd);
if (NULL != p)
{
CListCtrl &c = p->GetListCtrl();
if ((GetWindowLong(c.GetSafeHwnd(), GWL_STYLE) & LVS_REPORT) == LVS_REPORT)
{
for (int x = 0, nItem = -1; x < c.GetSelectedCount(); x++)
{
nItem = c.GetNextItem(nItem, LVNI_SELECTED);
if (-1 != nItem)
TRACE("Item = %d\n", nItem);
}
}
}
}
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
|
I believe includeh10 was interested in Windows Explorer, not Internet Explorer. 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Only Windows explorer in the moment.
I will test your code, thanks.
includeh10
|
|
|
|
|
IE looks like Explorer when it is showing a folder view
http://blog.joycode.com/jiangsheng
http://blog.csdn.net/jiangsheng
Command what is yours
Conquer what is not
---Kane
|
|
|
|
|
HWND hWnd=::FindWindow("ExploreWClass",0); is not working.
it may work on win95 only according to MSDN.
any more comments?
includeh10
|
|
|
|
|
includeh10 wrote:
HWND hWnd=::FindWindow("ExploreWClass",0); is not working.
Which means nothing unless you explain what "not working" means. Do you get a compiler/linker error? Does it fail to find a window with the indicated class name?
includeh10 wrote:
it may work on win95 only according to MSDN.
You need to re-read it again. The FindWindow() function is supported on Windows NT 3.1 and later, and Windows 95 and later.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
when we type a command on DOS window to execute a exe file, i.e.
regedit.exe
OS actually searches from a set of directories, if the file is not found, it shows error.
Do you know full list and searchong order of these directories?
thanks
includeh10
|
|
|
|
|
Per MSDN:
If the file name does not contain a directory path, the system searches for the executable file in the following sequence:
1) The directory from which the application loaded.
2) The current directory for the parent process.
3) Windows 95/98/Me: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
Windows NT/2000/XP: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
4) Windows NT/2000/XP: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
5) The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6) The directories that are listed in the PATH environment variable.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi DavidCrow,
thanks for extra info.
did you copy the info from MSDN?
two things need to know:
1. how to get "The directories that are listed in the PATH environment variable"?
2. "The current directory for the parent process" - what does it mean?
includeh10
|
|
|
|
|
includeh10 wrote:
did you copy the info from MSDN?
Yes, see this function, about 1/3 of the way down.
includeh10 wrote:
1. how to get "The directories that are listed in the PATH environment variable"?
To get the contents of any environment variable, use GetEnvironmentVariable().
includeh10 wrote:
2. "The current directory for the parent process" - what does it mean?
Exactly what it says.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
if for CreateProcess() ...
lets say:
c:\dir0\parent.exe and child.exe
CreateProcess(NULL,"child.exe",...) is called by parent.exe
1)The directory from which the application loaded.
2)The current directory for the parent process.
the 1) is c:\dir0 definitely.
the 2) should be c:\dir0 also, right?
my understanding is that 1) and 2) are the same.
includeh10
|
|
|
|
|
You know how you make an installer by packing a file under a
file then a footer under that.
When you use the file it uses the top file, so you make the top file read the footer to get the file sizes, read them into a buffer and write them out...
Well i was planing on using that same method to pack things like programs that are just dialogs under it, and have my program, (rather than write it to a file, and erase it afterwords, just execute it out of memory)... I could just make child windows, but this seems easyer to me, and i'm also mainly curious if it is really possile to do this...
|
|
|
|
|
Jabish wrote:
...rather than write it to a file, and erase it afterwords, just execute it out of memory...
This question has been asked several times in the past. Search CP for "PE file format."
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
You cannot run a file "from memory" because processes have separate address spaces. How would the new process read its code from yours?
Also, the OS uses memory-mapped files to load a binary into memory, which requires that the binary be a disk file.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | 1ClickPicGrabber | CP SearchBar v2.0.2 | C++ Forum FAQ
Strange things are afoot at the U+004B U+20DD
|
|
|
|
|
Can't you use malloc and get a chunk of memory big enough to hold the binary program, then manually load it from disk to memory? Next, use _beginthread/_beginthreadex and point it to the start of the memory you allocated? I know this probably isn't all you need to do, but that's what I'm thinking in a broadstroke. This wouldn't be it's own process either, it'll be a thread running under the guys process too.
|
|
|
|
|
Thank (all of you)... Just got back on so sorry i diddn't thank all of you earler.
Just wondering about the "PE file format" is it that PE projector thing?
also do I have to use any special way of reading the file to a buffer, or can I do it the way I always do:
<br />
FILE *in;<br />
<br />
long size;<br />
char *Buffer;<br />
<br />
if(in = fopen("[blah]", "rb"))<br />
{<br />
fseek(in, 0, SEEK_END);<br />
size = ftell(in);<br />
Buffer = (char *) malloc(size);<br />
fseek(in, 0, SEEK_SET);<br />
<br />
fread(Buffer, 1, size, in);<br />
<br />
fclose(in);<br />
}<br />
----------
and then do the PE thing, or do i need to use ReadFile() or something...
If possible a specific code example would be appreicated, (haven't tried anything like this before) just a little confused.
PS:
wasn't planning on using this idea for a child window type deal... I was thinking more on the line of something like:
a patcher like there is before you log on to a game, after the patcher got it's files it could unpack and execute parts of the game, or the game could just unpack the patcher... that kind of thing. I don't actually NEED this, am just curious about it. Thanks again =8^)... please don't steal face... 
|
|
|
|
|
Jabish wrote:
Just wondering about the "PE file format" is it that PE projector thing
The example that I have seen, and may still have on my disk at work, requires knowledge of the Portable Executable file format.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
