C / C++ / MFC Discussion Boards

Another tip (from David Crow, actually):
Look at your environment variable ProgramFiles.
Is it there? Does it point to something reasonable?

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

Take the driver letter returned from GetSystemDirectory() or GetWindowsDirectory(), and append "\\Program Files" to it.

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Hmmmpf.
IIRC, Windows 98 did localize its program path.
In Germany, we already had "\\Programme".

But I do not have a Windows98 ready to check it.

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

What is the value of your ProgramFiles environment variable?

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

I have no Win98 bootable here, but I remember hassles with the translation back then.
Here in the company I am currently working on a US WinXP with German locale settings. So I couldn't even tell for German WinXPs...

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

I just looked it up for a German W2K:
There its pointing to "C:\Programme"

Not that this does help the OP, though.

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

jhwurmbach wrote:
Not that this does help the OP, though.

Why not?

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

He asked specifically for Win98.
That is software-archeology! Smile | :)

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

jhwurmbach wrote:
He asked specifically for Win98.

Does the ProgramFiles environment variable exist on that OS?

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

As I said, I don't have Win98 bootable here.
All I have are German WinXP and W2k, and both have %ProgramFiles, and it points to "C:\Program Files"

But MSDN says:
"SHGetFolderPath is a superset of SHGetSpecialFolderPath, included with earlier versions of the Shell. On systems preceeding those including Shell32.dll version 5.0 (Windows Millennium Edition (Windows Me) and Windows 2000), SHGetFolderPath was obtained through SHFolder.dll, distributed with Microsoft Internet Explorer 4.0 and later versions. SHFolder.dll always calls the current platform's version of this function. If that fails, it will try to simulate the appropriate behavior. SHFolder.dll continues to be included for backward compatibility, though the function is now implemented in Shell32.dll."

And CSIDL_PROGRAM_FILES is specifically mentioned as supported. That sounds as if this would work with Win98!

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

jhwurmbach wrote:
As I said, I don't have Win98 bootable here.
All I have are German WinXP and W2k, and both have %ProgramFiles, and it points to "C:\Program Files"

Ok, but what does this have to do with my suggestion not being a possible solution for the OP? The only way it would not help is if that OS did not have the ProgramFiles environment variable. Since you cannot confirm one way or the other, how can you claim that it is not a viable solution?

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

DavidCrow wrote:
The only way it would not help is if that OS did not have the ProgramFiles environment variable.

OK, you are right. All I have to say in my defence is I am just starting the eleventh hour at work.

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

Hi Experts,
How can I add icon to ListView?

You can use of SetImageList.

I used like this

<br />
CImageList ImageList;<br />
				ImageList.Create(16, 16, CLR_NONE, 0, 255);<br />
				ImageList.Add(sfi.hIcon);//HICON<br />
				ListCtrl.SetImageList(&ImageList, LVSIL_SMALL);<br />
							<br />
			ListCtrl.InsertItem(ListCtrl.GetItemCount(),finder.GetFileName(),0);<br />

But this code is giving exception at
ImageList.Add(sfi.hIcon);//HICON

Could you please me?

Explain the exception that you see -- is it stopping on an ASSERT?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<a href="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</a>

Debug Assertion failed

that doesn't seem like much information.

that's all the assertion says?

It doesn't sound like you ran this in the debugger -- it should stop a specific line of code.

THAT'S YOUR CLUE.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<a href="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</a>

What line of what file is asserting?

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Are you sure ImageList is created? did you check return value of Create what was it?

Dev environment: vc6.0 + SP5
System : WinXP + SP2

Some threads(include main UI thread and other NonUI worker threads) will call PostThreadMessage to post user-defined message to a NonUI worker thread. In this case, the user-defined message is WM_USER+0x2000.
The nonUI worker thread created by AfxBeginThread, and i override the Run function.The code is like below:
WorkThread::Run()
{
while ( 1 )
{
::PeekMessage ( &Msg, 0, 0, PM_NOREMOVE ) ;
if ( Msg.message == WM_USER+0x2000 )
TRACE ( "MESSAGE\n" );
........
........
if ( ... )
break;
}
}
Note: WM_USER+0x2000 post by main UI thread and PostThreadMessage return TRUE.But i cann't trace the message.Other user-defined message post by
PostThreadMessage will be received in WorkThread::Run(), i don't why?
which logical error or system bug will cause the problem?

CNJXRZ wrote:
PostThreadMessage will be received in WorkThread::Run(), i don't why?

I just tried ur code and I am getting the message also. the only difference i made was instead of a CWinThread derived class, i wrote only a thread proc. Also why its only 4 parameters in ur PeekMessage() function? It actually takes 5 paramters. isnt it?

UINT __cdecl MyControllingFunction( LPVOID pParam )<br />
{<br />
<br />
	MSG Msg;<br />
	while ( 1 )<br />
	{<br />
		::PeekMessage( &Msg, 0, 0,0, PM_NOREMOVE ) ;<br />
		if ( Msg.message == WM_USER+0x2000 )<br />
			TRACE ( "MESSAGE\n" );<br />
	}<br />
	return 0;<br />
}<br />
void CDialogBasedDlg::OnButton1() <br />
{<br />
	CWinThread *pthread =  AfxBeginThread( MyControllingFunction, 0 );<br />
	PostThreadMessage( pthread->m_nThreadID, WM_USER + 0x2000, 0 ,0 );<br />
}

nave

[OpenedFileFinder]

CNJXRZ wrote:
user-defined message is WM_USER+0x2000

<pet peeve alert>
You should be using WM_APP instead of WM_USER. From the documentation (emphasis mine)

Message numbers in the second range (WM_USER through 0x7FFF) can be defined and used by an application to send messages within a private window class. These values cannot be used to define messages that are meaningful throughout an application, because some predefined window classes already define values in this range. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use these values.Messages in this range should not be sent to other applications unless the applications have been designed to exchange messages and to attach the same meaning to the message numbers.

Message numbers in the third range (WM_APP through 0xBFFF) are available for application to use as private messages. Message in this range do not conflict with system messages.
</pet peeve alert>

Judy

CNJXRZ wrote:
The nonUI worker thread created by AfxBeginThread,

Using which version of AfxBeginThread()?

Technically, if your Run() override gets called, then
it's a UI thread, not a worker thread. Smile | :)

Is your Run() override getting called? If not, you're using
the wrong AfxBeginThread().

Note that you don't have a message queue on that thread until the
first PeekMessage() call. Are you posting the message before that
call?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

How to find the threadIdentifier of an HWND ?

Thanks & Regards