|
There are LOTS of utilities (executables) for mounting ISO files to drive letters, but I want to open and read the contents of an ISO file through some kind of library, not a separate EXE. Any way to do that? I don't mind mind mounting the ISO to a drive letter or directory, I just don't want to make the user do it manually.
|
|
|
|
|
You could add the ISO reading functionality to a DLL or COM Object and use it that way.
You'll probably have to write the ISO code yourself, but it's not too difficult and there is a full ISO spec on the web.
Google for ISO9660, Joliet, etc, here is the wikipedia[^] entry for example.
|
|
|
|
|
It's not that critical, just a "nice to have" for my app. Besides, if it was that easy, it seems like there would already be a free code library available for this. Heck, my boss may even be willing to pay a reasonable price for one.
|
|
|
|
|
Hi, I added code for supporting multiple languages and are suprised about the following behaviour of Windows XP.
I have an English Windows version and selected English (United Kingdom) as my user interface language, I verified this in Control Panel -> Regional and Language Options. The function GetUserDefaultUILanguage from kernel32.dll returns 0x0409 (ENU, United States) and GetSystemDefaultLangID returns 0x0809 (ENG, United Kingdom)... shouldn't they both return the same?
Thanks for help
/M
|
|
|
|
|
What does GetUserDefaultLangID() and GetThreadLocale() return? I've always used those.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
Jim Crafton wrote: GetUserDefaultLangID()
A current user locale - formatting stuff mostly, like currency, and date/time. Can be set from Control Panel->"regional and language options"->"regional options" tab.
Jim Crafton wrote: GetThreadLocale()
The same as the user locale - only on per-thread basis. It can be set programmatically.
|
|
|
|
|
GetSystemDefaultLangID() returns the system locale. This is used to determine which code page is used for non-Unicode (aka "ANSI") text on a system. It can be changed (on XP) from the advanced tab on the "regional and language options" in Control Panel (probably needs to be rebooted before the change takes effect)
GetUserDefaultUILanguage()
returns the current UI language which can be set by a user if MUI pack is installed.
|
|
|
|
|
Thanks for the info. What I don't understand that if I detect the language according to MSDN[^] then I would detect the wrong language (in a case where both UK and US language resources are available for an application).
GetUserDefaultUILanguage() Win32 API: 0x0409 US English
GetSystemDefaultUILanguage() Win32 API: 0x0409 US English
GetSystemDefaultLangID() Win32 API: 0x0809 UK English
What would be the correct order in an application to check?
modified on Monday, April 14, 2008 12:21 PM
|
|
|
|
|
Moak wrote: What would be the correct order in an application to check?
I am not sure what you are trying to check from your application. The link you left points to the article explaining how MFC is choosing a satelite dll.
|
|
|
|
|
Nemanja Trifunovic wrote: I am not sure what you are trying to check from your application. The link you left points to the article explaining how MFC is choosing a satelite dll.
Quote from MSDN: MFC attempts to load the resource DLL for each of the following languages in order, stopping when it finds one.
It starts with GetUserDefaultUILanguage(), which returns ENU (US English) on my computer which is wrong as I have ENG (UK English). If the application is delivered with both US and UK english satelite DLLs, the wrong English language would be auto detected.
/M
|
|
|
|
|
Moak wrote: It starts with GetUserDefaultUILanguage(), which returns ENU (US English) on my computer which is wrong as I have ENG (UK English).
Based on what you described it is not wrong. The value returned by GetUserDefaultUILanguage() can be set by the user on XP Pro with MUI pack installed with the "Language used in manus and dialogs" option only.
What exactly did you do to set the language to UK English in Control Panel? My guess is that you changed either user locale (dates, currency, etc), input locale (kayboard) or both, but it does not affect the default UI language.
The value GetUserDefaultUILanguage() returns tells about the language of the menues, etc in Windows. As I said, you can't change it with Windows XP unless you have MUI pack installed.
|
|
|
|
|
Well, thanks for taking the time to explain! To answer your question, in the control panel -> Regional and Language Options -> tabs (Regional/Languages/Advanced) the language is set to "English (United Kingdom)", I didn't change it after Windows installation. I don't have a MUI pack installed as far as I know.
I think something is wrong... because with my settings I would expect "English (United Kingdom)" to be detected... but I am not sure what it is (my code or the explanation in the MSDN article).
Cheers!
|
|
|
|
|
Moak wrote: Well, thanks for taking the time to explain!
You're welcome. I know international programming can be frustrating - after all I worked in language/localization industry 7 years before I finally had enough 
Moak wrote: in the control panel -> Regional and Language Options -> tabs (Regional/Languages/Advanced) the language is set to "English (United Kingdom)",
OK. If you read carefuly the explanation on that tab, you'll see that it sets the "Language for non-Unicode programs", or "system locale". What it does is determine which code page is used for multibyte ("ANSI") characters. For instance, when you use MultiByteToWideChar function, and set the CodePage parameter to CP_ACP, it will be this setting that decides from which multibyte encoding we are converting to Unicode. Mind you, all Windows API functions internaly do that if the application does not compile as UNICODE. This value gets returned by GetSystemDefaultLangID as you already noticed.
However, GetUserDefaultUILanguage does not look into this setting at all! It returns the language in which the UI controls of your OS are rendered (and MFC correctly looks at that one first - after all you would want your application to e displayed in the same language as the OS). This setting you can change on Windows XP Pro only if you have MUI pack installed, and in that case you'll have a combo box "Language used in menues and dialogs" displayed in the "Language" tab in the Control Panel "Regional and Language Options". Otherwise, it is just predetermined by the version of Windows you installed (En-UK, or En-US) and you can't change it.
Hope it is a little clearer now
|
|
|
|
|
All of the answers you seek can be found by reading the articles from Dr. International.[^]
The only question he cannot answer is about his true identity which is a closely guarded secret.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: The only question he cannot answer is about his true identity which is a closely guarded secret.
Dr International is a nickname for a group of people, and their names can be found in the "Acknowledgements" section of their book[^]
|
|
|
|
|
It was a joke referring to the bottom of the link I posted. 
Who is Dr. International?
Dr. International's identity is one of the most closely guarded secrets of Microsoft. Since (1) he has the support and help of the entire Windows International Division, (2) he is very knowledgeable about i18N issues, and (3) he gets to choose what questions/answers are posted, he can maintain the illusion of knowing everything.
|
|
|
|
|
Anyone else see the strange format bug?
I cannot even see the Edit link to modify the post...
|
|
|
|
|
I had wanted to customize the tree control by adding a header. I wanted to do the same thing the list view control does and simply add the header as a child of the tree wnd at the top of it's client rect. I got this to work OK, but when it paints it of course covers the first item of the tree ctrl. No problem I thought, I'll just override the WM_PAINT and use SetViewportOrgEx and shift the HDC's y origin up by the height of the header. That seemed to work OK. But when I clicked on an item, things would not get drawn correctly. It's as if it got shifted down too much or copied from the wrong point. If a full repaint occured then things looked OK, but if a the paint rect for the WM_PAINT was a partial, then there seemed to be nothing I could do to get it to paint correctly.
I overrode the CUSTOM_DRAW callback and verified that the correct items were getting processed. They just don't seem to show up where you would expect them. What am I missing?
Here's the default tree with one item and one child item underneath it:
pic1.PNG[^]
Now if you click on the + to open it up:
pic2.PNG[^] - obviously that's not right! the partial update doesn't seem to get handled correctly.
If you resize the window:
http://www.vcf-online.org/tmp/pic3.PNG[^]
After some experimenting, the problem seems to revolve around the use of the SetViewportOrgEx call. If that is not called, the first item will not show, but the updates will be processed correctly (for example, if you add more items to the tree and try opening/closing them). But if you then adjust the origin with SetViewportOrgEx then the painting gets screwed up.
Note: I have NOT solved this problem - at the moment I'm completely stumped as to why it doesn't work right and what I can do to fix it.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
modified on Monday, April 14, 2008 11:16 AM
|
|
|
|
|
Glad to hear you solved the problem. I'll have to keep this approach in mind in the future.
An alternative that I use myself, is to just handle the WM_NCCALCSIZE & WM_NCPAINT messages. For example
LRESULT CLeftView::OnNcCalcSize(WPARAM wParam, LPARAM lParam)
{
RECT *prect = (RECT *)lParam;
WndProcDefault(GetHwnd(), WM_NCCALCSIZE, wParam, lParam);
m_ncRect.left = prect->left;
m_ncRect.right = prect->right;
m_ncRect.top = prect->top;
m_ncRect.bottom = prect->top + 22;
prect->top += 24;
SCROLLBARINFO sbi;
::ZeroMemory(&sbi, sizeof(SCROLLBARINFO));
sbi.cbSize = sizeof(sbi);
if (::GetScrollBarInfo(GetHwnd(), OBJID_VSCROLL, &sbi))
if (!(sbi.rgstate[0] & STATE_SYSTEM_INVISIBLE))
m_ncRect.right += ::GetSystemMetrics(SM_CXVSCROLL);
return 0L;
}
and
LRESULT CLeftView::OnNcPaint(WPARAM wParam, LPARAM lParam)
{
WndProcDefault(GetHwnd(), WM_NCPAINT, wParam, lParam);
HDC hDC = ::GetWindowDC(GetHwnd());
RECT rc;
rc.left = m_ncRect.left;
rc.right = m_ncRect.right;
rc.top = m_ncRect.bottom;
rc.bottom = m_ncRect.bottom + 2;
HBRUSH hBrush = ::CreateSolidBrush(RGB(248, 249, 252));
::FillRect(hDC, &rc, hBrush);
::DeleteObject(hBrush);
if (isThemed != 0)
drawVistaTitleBar(hDC, "Item Library");
else
DrawTitleBar(hDC);
::ReleaseDC(GetHwnd(), hDC);
return 0L;
}
Thanks to WM_NCCALCSIZE's code the scroll-bars draw correctly too. http://i291.photobucket.com/albums/ll304/enhzflep/treeView.jpg[^]
|
|
|
|
|
I didn't solve the problem. That's why I posted here 
I only "seem" to have narrowed the problem down to the presence or absence of a particular function call. Unfortunately I don't know how to get it to work right.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
What would be nice is if I could expand the NC area and put the header in there. But I don't think I can do that can I? Plus how would the header respond to mouse events, dragging, etc?
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
Well this code is written using win32++ as I don't have access to a mfc enabled copy of VS, but I'd (foolishly?) assume that it would work just the same in either case.
The code I posted will decrease the size(height) of the window, while increasing the size(height) of the non-client area.
The header will respond in just the same way as the non-client area for a tree control normally will. The window proc for this control only handles WM_NCCALCSIZE and WM_NCPAINT messages, passing any others to the original wind proc.
Here's what the wind proc for the class looks like in it's entirety:
LRESULT CLeftView::WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_NCCALCSIZE:
return OnNcCalcSize(wParam, lParam);
case WM_NCPAINT:
return OnNcPaint(wParam, lParam);
}
return WndProcDefault(hWnd, uMsg, wParam, lParam);
}
I'm afraid I have no recollection of where I picked this trick up, though it seems to work just fine. If I've left things unexplained, or you like the class source, I'd be happy to expand on what I've said, or mail you a copy of the class.
Simon.
[EDIT: Oops, looks like I misread that first post. Sorry 'bout that Jim. I've not used the functions you mention before, I'll see if I cant come up with something that achieves this affect using them.]
modified on Monday, April 14, 2008 12:25 PM
|
|
|
|
|
Hi,
I want to find all title of windows. But the code is giving 2 errors:
code is:
<br />
void CMainFrame::TrackWindow()<br />
{<br />
HWND hwnd;<br />
LPARAM lParam = 0; <br />
<br />
while(EnumWindows((WNDENUMPROC)EnumWindowsProc,lParam))<br />
{<br />
EnumWindowsProc(hwnd,lParam);<br />
}<br />
}<br />
<br />
static BOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM lParam)<br />
{<br />
char text[200];<br />
GetWindowText(hwnd,text,200);<br />
AfxMessageBox(text);<br />
return TRUE;<br />
};<br />
<br />
Erros are:
1.'type cast' : cannot convert from 'overloaded-function' to 'WNDENUMPROC'
2. unable to recover from previous error(s); stopping compilation
|
|
|
|
|
1) Do you have a prototype for your callback function before the call to EnumWindows?
2) <pet peeve> Change the name of the callback function to something other than the default. </pet peeve>
Judy
|
|
|
|
|
Thank you, Its working but I want to know the WindowPlacement using GetWindowPlacement() . The below code is returning null in WINDOWPLACEMENT variable.
<br />
static BOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM lParam)<br />
{<br />
char text[200];<br />
GetWindowText(hwnd,text,200);<br />
CString szWindowTitle=text;<br />
WINDOWPLACEMENT *WndPlacement=NULL;<br />
if(szWindowTitle=="My Window")<br />
{<br />
GetWindowPlacement(hwnd,WndPlacement);
szWindowTitle.Format("%d",WndPlacement->showCmd);<br />
AfxMessageBox(szWindowTitle);<br />
}<br />
<br />
return TRUE;<br />
};<br />
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
