|
Is it redistributable?
--
Must I be the meat in an imbecill sandwich?
|
|
|
|
|
It's part of windows - it must be totaly redistributable.
|
|
|
|
|
AK wrote:
It's part of windows
It's not part of Win9x/ME, so it might not have been redistributable. But it so happens that it is redistributable.
|
|
|
|
|
In other words; MS won't be pissed if I redistribute it in an app which will run (mostly) on win2k?
I saw a discussion on this a looong time ago. I wish I had payed more attention. 
--
Must I be the meat in an imbecill sandwich?
|
|
|
|
|
|
|
Hi anyone know where in the registry the default email client is located and is it the same in all window flavors?
Best Wishes,
ez_way
|
|
|
|
|
Files with extension *.eml are opened by the default mail client when double clicked.
HKEY_CLASSES_ROOT +
the default value of
HKEY_CLASSES_ROOT\.eml
which is on my XP
"Microsoft Internet Mail Message" +
shell\open\command
contains the registry key with the full path and command line of the default mail client:
so look at the default value of
HKEY_CLASSES_ROOT\Microsoft Internet Mail Message\shell\open\command
This is
"%ProgramFiles%\Outlook Express\msimn.exe" /eml:%1
on my XP without Office being installed.
Peter Molnar
|
|
|
|
|
Great stuff Peter! To explain I want to store the mail client information for later use.
Yes I too only have OlExpress but I like it. As for office they want so much for 2003 I went open office.
Seems that HKEY_LOCAL_MACHINE\\SOFTWARE\\Clients\\Mail\\ is the path on the new os's but do you know if it would be good on all 32b os's?
HKEY_CLASSES_ROOT\Microsoft Internet Mail Message\shell\open\command
If I use your idea will that return the complete path or as you said
"%ProgramFiles%\Outlook Express\msimn.exe" /eml:%1
Also Sardaukar wrote in part in his artice "Detect and run the default mail client" codeproject 2002
BOOL GetCmdLine()
{
LONG retval;
retval = Open(HKEY_LOCAL_MACHINE, m_szDefMailClient);
if(retval == NO_ERROR)
{
DWORD cbData = _MAX_PATH;
retval = ReadString(m_szDefMailClient, cbData);
if(retval == NO_ERROR)
{
TCHAR szCmdLine[_MAX_PATH + 1];
lstrcpyn(szCmdLine, _T("SOFTWARE\\Clients\\Mail\\"),
_MAX_PATH + 1);
_tcsncat(szCmdLine, m_szDefMailClient, _MAX_PATH + 1);
_tcsncat(szCmdLine, _T(\\shell\\open\\command),
_MAX_PATH + 1);
RegKey_ rk;
if(rk.Open(HKEY_LOCAL_MACHINE, szCmdLine) == NO_ERROR)
{
retval = rk.ReadString(m_szDefMailCmd, _MAX_PATH);
if(retval == NO_ERROR)
{
return TRUE;
}
}
}
}
return FALSE;
}
Problem it does not work on all os's.
Any idea's??
Best Wishes,
ez_way
|
|
|
|
|
With the key HKEY_LOCAL_MACHINE\\SOFTWARE\\Clients\\Mail\\ the problem is that some other (non M$) mail client/or older M$ clients might not support it.
The above suggestion of mine uses the way the OS works, i.e. looking up the associated exe file of the email file extension, and as such should always work. Never assume that the default value of HKEY_CLASSES_ROOT\*.eml is "Microsoft Internet Mail Message", always look for its value. That's what the OS does, too, when you doubleclick a file.
Peter Molnar
|
|
|
|
|
Just one more thing:
You can also look for the default value of
HKEY_CLASSES_ROOT\mailto\shell\open\command
which gets looked up by the OS when you click on a <a href='mailto:...'> in a webpage, and that on all OS's.
Peter Molnar
|
|
|
|
|
void CTestDlg::OnButton1()
{
HKEY hkey;
char szKey[1024];
strcpy(szKey, "\\mailto\\shell\\open\\command");
if (RegOpenKeyEx(HKEY_CLASSES_ROOT,
szKey,
0,
KEY_QUERY_VALUE,
&hkey) == ERROR_SUCCESS) {
// Do something!
RegCloseKey(hkey);
}
}
Yes fine work, GREAT Help!
Here is where I am, I can find the key but now I must read it in place it in var.
I was thinking I could use RegQueryValueEx but it return LONG...
Will let you know later
Thank you so very much!
LONG RegQueryValueEx(
HKEY hKey, // handle to key to query
LPTSTR lpValueName, // address of name of value to query
LPDWORD lpReserved, // reserved
LPDWORD lpType, // address of buffer for value type
LPBYTE lpData, // address of data buffer
LPDWORD lpcbData // address of data buffer size
|
|
|
|
|
Use ExpandEnvironmentString to get rid of %Program Files%
Peter Molnar
|
|
|
|
|
Hi Peter I have to give up for awhile as I am going nuts over grabbing this rkey.
Thanks
again for your help!
Best Wishes,
ez_way
|
|
|
|
|
Hi Peter
Is not ExpandEnvironmentString a VB function?
Best Wishes,
ez_way
|
|
|
|
|
Try this:
HKEY hKey;
TCHAR szDefaultMailClientPath[MAX_PATH] = {0};
DWORD dwSize = MAX_PATH;
if (RegOpenKeyEx(HKEY_CLASSES_ROOT, _T("mailto\\shell\\open\\command"), 0, KEY_READ, &hKey) == ERROR_SUCCESS &&
RegQueryValueEx(hKey, _T(""), 0, NULL, (BYTE*)&szDefaultMailClientPath, &dwSize) == ERROR_SUCCESS)
{
CString sPathWithCL(szDefaultMailClientPath);
CString sPath = sPathWithCL.Mid(sPathWithCL.Find('"') + 1,sPathWithCL.ReverseFind('"') - sPathWithCL.Find('"') - 1);
CString sEnvString = sPath.Mid(sPath.Find('%'),sPath.ReverseFind('%') - sPath.Find('%') + 1);
if (sEnvString.GetLength())
{
TCHAR szEnvStringResolution[MAX_PATH] = {0};
ExpandEnvironmentStrings(sEnvString,szEnvStringResolution,MAX_PATH);
sPath.Replace(sEnvString,szEnvStringResolution);
}
MessageBox(sPath);
}
Peter Molnar
|
|
|
|
|
Hi Peter that work now explainit please!
if (sEnvString.GetLength()) { // check that there is a value
TCHAR szEnvStringResolution[MAX_PATH] = {0}; //set to NULL
ExpandEnvironmentStrings(sEnvString,szEnvStringResolution,MAX_PATH); // really confused here
sPath.Replace(sEnvString,szEnvStringResolution); // this one I understand
What I am trying to understand is how the macro gets the env path?
Thanks again!
Best Wishes,
ez_way
|
|
|
|
|
if (sEnvString.GetLength())
{
TCHAR szEnvStringResolution[MAX_PATH] = {0};
ExpandEnvironmentStrings(sEnvString,szEnvStringResolution,MAX_PATH);
sPath.Replace(sEnvString,szEnvStringResolution);
}
MessageBox(sPath);
Peter Molnar
|
|
|
|
|
Could someone please explain:
1, what exactly do those function decorators mean, such as WINAPI, FAR, PASCAL, CALLBACK, and much more?
2, what happens if I remove the decorator from a function, for example,
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
vs
int WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
what's the difference between them?
Thanks a lot.
|
|
|
|
|
Those are used to define the behaviour of the function's call-stack and addressing.
PASCAL means that the parameters passed to that function are arranged backwards on the stack as compared to the C/C++ calling convention. WINAPI is the same as FAR PASCAL. FAR means the function uses 32-bits for addressing. I'm not sure exactly what CALLBACK means.
You shouldn't remove them!
|
|
|
|
|
Terry O`Nolley wrote:
I'm not sure exactly what CALLBACK means.
CALLBACK is the same as __stdcall which is the same as PASCAL 
--
Must I be the meat in an imbecill sandwich?
|
|
|
|
|
|
There are two basic ways of passing parameters to a function: right-to-left and the caller removes them from the stack once the function is done, or left-to-right and the function itself removes them. The former is called cdecl and the latter stdcall. All those macros (aside from FAR) resolve to either __cdecl or __stdcall and denote the function's calling convention. They tell the compiler how to handle the parameters when the function is called.
You can ignore FAR since that is a leftover from the days of segmented memory architectures. All that went away with Win32 and its flat memory model. The various macros that all resolve to the same thing (like PASCAL and CALLBACK) used to be different things, but again that's all gone away in Win32.
[VS hint: highlight a macro and press F12 to jump to its definition.]
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
You cannot stop me with paramecium alone!
|
|
|
|
|
Your answers really helped, I appreciate.
So all functions have type of either _cdecl or _stdcall (functions are _cdecl by default?), and neither of them are important anymore in Win32. But were they important in Win16? If I messed up with the two types in a Win16 application, what would go wrong?
|
|
|
|
|
They do important in Win32. First and foremost __cdecl and __stdcall identify a calling convention of a function.
Calling convention includes 2 major things:
- argument passing order in the stack
- stack cleaning responsibility.
A code of a function and a code of a call to that function must agree and support the same calling convention. Because these codes can be located in differnt compilation units (files), the information about calling convention must be known by linker, alltogether with the function name. This information is passed to linker in the form of a decorated function name. Decoration schemes for __cdecl and __stdcall types of call are different.
That means that if we have, for example, __cdecl function defined in one file and declaration of this funcion as __stdcall in another file (say, by mistake), we will not be able to call this function from another file. The linker will complain about unresolved external symbol.
Note that C++ uses other than C decoration schemes both for __cdecl and __stdcall.
bni777
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
