|
I have two zip files
1. Normal
2. Corrupted
When in windows explorer when you take the cursor over
1 the normal zip file the tooltip shows-- zip file
2 the corrupted zip file the tooltip shows -- no zip file or bad zip file.
how can i achieve this file description in VC++
By using version info we can get the file description but that file needs to be an application it is not possible for normal files.
|
|
|
|
|
|
I'm trying to get the Target Folder path from a Folder Shortcut PIDL and I can't seem to find where this is or how to get it. From everything I've read it looked like a "simple" matter of binding an LPSHELLFOLDER variable to the PIDL, performing a QueryInterface (using IID_IPersistFolder3) and then calling its GetFolderTargetInfo method to get the goods. But it doesn't work. It looks like I can get the pointer to the Folder Shortcut's Shell Object, and it seems like the QueryInterface call succeeds to get a pointer to the IPersistFolder3 interface, but when I perform the GetFolder, the path values are empty and the PIDL doesn't look to be the same PIDL (in terms of its values not the address) I used on the BindToObject. I've been going round and round with this. Windows Explorer is privy to this information (shows up in the 'Target:' section of the Properties pop-up) so there's gotta be a way to get it. I need it to build a complete UNC or mapped drive path in my mini-browser for my app.
I've also tried seemingly obvious APIs like SHGetPathFromIDList() but this produces a path to the shortcut in the Documents folder, not the actual Target Folder. Any help would be greatly appreciated. Thanks in advance!
-Mike
P.S. Code snippet:
IPersistFolder3 * pPersistFolder = NULL;
IShellFolder * pSubFolder = NULL;
// pEnum->pshfParent references the 'My Network Places' PIDL in
// this scenario
hr = pEnum->pshfParent->BindToObject(
pItemIdList, // [in] folder shortcut PIDL
NULL,
IID_IShellFolder,
(VOID**) &pSubFolder);
// hr == S_OK && pSubFolder
hr = pSubFolder->QueryInterface(
IID_IPersistFolder3,
(VOID **) &pPersistFolder);
// hr == S_OK && pPersistFolder
PERSIST_FOLDER_TARGET_INFO targetInfo;
memset(&targetInfo, 0x00, sizeof(PERSIST_FOLDER_TARGET_INFO));
hr = pPersistFolder->GetFolderTargetInfo(
&targetInfo);
// Doesn't give the Target Location!
|
|
|
|
|
I know it's not healthy to talk to yourself, but I was able to solve this problem and thought I'd relay the fix in case anyone else was interested. I needed to use the IShellLink interface instead of the IPersistFolder3, using IShellLink::GetPath to get the UNC path.
|
|
|
|
|
I want to know if a dialog based program can be in the following style.
1. there is a title bar;
2. there is no caption on the title bar;
3. there is a caption on the windows task bar button.
<font=sans-serif>|-|3llo Wo|2ld
|
|
|
|
|
1. there is a title bar;
BOOL bHasTitleBar = this->GetStyle() & WS_CAPTION;
2. there is no caption on the title bar;
CString sCaption;
this->GetWIndowText(sCaption);
BOOL bHasCaptionOnTheTitleBar = sCaption.GetLength() > 0;
3. there is a caption on the windows task bar button.
BOOL bHasTaskBarButton = (this->IsWindowVisible() && this == AfxGetMainWnd());
|
|
|
|
|
=[ Abin ]= wrote:
// Huh? If a window has caption on its title bar, then
// it also has the same caption on the system task bar button,
// if it does have a task bar button.
// If you mean "this window has a task bar button"
I mean this window has a task bar button with caption as well as a title bar without caption. The requirements are quite strange and make me hard to implement. I am now considering if i can set the caption color to transparent or to the same of the title bar. Do you have any idea?
Thanks very much
<font=sans-serif>|-|3llo Wo|2ld
|
|
|
|
|
Requirements 2 & 3 collide. As you already know...
But you can cheat. Set a title as you normally would. Then handle the WM_NCPAINT message
and draw the title bar yourself (and don''t bother drawing the text!).
For examples of custom title bars, search codeproject for WM_NCPAINT and OnNcPaint.
And I agree, it is a strange request!
Iain.
|
|
|
|
|
Hi all,
I have an ASCII file, i want to read the content of the file, and then display it on the CRichEditCtrl. The point is i want to display all the control characters (especially \t \r \n) as a symbol (like a square) instead of interpreting it (e.g. making spaces for \t).
Really appreciate if s.o could help.
Thanks
|
|
|
|
|
So how about reading the contents of the file into a CString object, and use the Replace() method to replace all \t \r \n characters with said square?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Hello guys,
I'm wondering if anyone could help me to better undestand the exact OnClose() behaviour.
To start clearly, I have an dialog-based application that has a child dialog with a Exit button. When the button is clicked, the child dialog can therefore notify to close the application by sending a message (SendMessage()) to a parent dialog's function, which leads OnClose(), the function looks like:
LRESULT ParentDlg::OnExitApp(WPARAM wParam, LPARAM lParam)
{
OnClose();
return 0;
}</code>
I need to do some clean-up before the application is closed, so I override the OnClose() function:
void ParentDlg::OnClose()
{
DoSomeCleanUp();
CDialog::OnClose();
}</code>
MSDN says OnClose() that its default implementation calls DestroyWindow. So I call the base class handler CDialog::OnClose() at the end of overriden OnClose() and assumes that should call DestroyWindow(), which leads to ParentDlg::OnDestroy()
I run in debug mode and found that, if the application is to close by clicking on the "X" of the application, fair enough, OnClose() is called and it goes to OnDestroy() and the program exits (with return code code 2 (0x2) -- strange??). However, if it is to close via the Exit button in the child dialog, which goes through OnExitApp(), OnClose(), then OnDestroy() never gets called after and the program will not exit. Why is the behaviour different when both call CDialog::OnClose() eventually?
I later simply insert the code DestroyWindow(); to the OnClose() function and that made both call OnDestroy() and both now exit the program. However here that produces another different behaviour. The program return code is now code 0 (0x0). Can anyone explain?
Sorry for this lenthy post 
Thanks
|
|
|
|
|
Hi,
When you push the X button in an app, some messages are send to your app. One of those messages is the WM_DESTROY message, which doesn't get send when you push the Exit button in your dialog.
One solution is (only when it is a modal dialog) to use the OnOK (or OnCancel) message handler. This will terminate the dialog and return the DoModal funtion will return a value.
Hope this helps.
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
LRESULT ParentDlg::OnExitApp(WPARAM wParam, LPARAM lParam){
OnClose();
return 0;
}
Is why.
Change it to
LRESULT ParentDlg::OnExitApp(WPARAM wParam, LPARAM lParam){
SendMessage(WM_CLOSE);
return 0;
}
When CDialog::OnClose gets called, it calls MFC's Default() method - which says hay what was the last message? Lets pass that to DefWindowProc for processing. If you just _call_ OnClose, the last message will be your custom message you are using to close the dialog - and DefWindowProc will do nowt.
Better yet - do away with your custom message and just send the dialog a WM_CLOSE from the other dialog.
|
|
|
|
|
J.B. wrote:
I run in debug mode and found that, if the application is to close by clicking on the "X" of the application, fair enough, OnClose() is called and it goes to OnDestroy() and the program exits (with return code code 2 (0x2) -- strange??).
Not strange at all. This is the expected return value when the "X" is clicked. If this is a modal dialog, look at the EndDialog() function. It gets called whenever a modal dialog is dismissed. Alt+F4, Cancel, and the "X" all effectively call EndDialog(2). This value, in turn, gets passed back through DoModal(). Had you dismissed the dialog using the OK button, EndDialog(1) would have been called instead.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Thanks alot guys,
it all makes sense now 
|
|
|
|
|
Has anybody goten the free 2003 compiler to work in VC++6
If so how did you do it
Thanks
|
|
|
|
|
How come no one ever ansewers ?'s about .net
i think yall are sissies
|
|
|
|
|
Anonymous wrote:
Has anybody goten the free 2003 compiler to work in VC++6
Yes.
Anonymous wrote:
If so how did you do it
Set the path to executables in the VC++ Options to specify the path to the VC++ 2003 compiler before the VC++6 compiler.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
But thing that compile fine with 6 bring up numerous
errors when compiled with the new .net
why
|
|
|
|
|
Because VC.NET is much more standards-compliant than VC6. Some things that VC6 allowed are now errors.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan, what kinds of projects are you using it with?
I'm working on a fairly complex library, but with no UI or Windows calls.. and I'nm finding that the libs I need are not there.
|
|
|
|
|
I only used it once. I didn't have any problems with the libraries (it was a MFC based application with DirectX etc. as well), but the VC6 debugger couldn't interpret the debugging information it put in the executable, so I canned it pretty quickly.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ooh - strike three, it's out!
Thanks.
|
|
|
|
|
Hey,
I am trying to get text from a combo box in a different dialog, and how I did it I get an error.
Here is how I did it.
<br />
CDialog1::m_minCHO.GetWindowText(sText196);<br />
CDialog1 is the class, and the m_minCHO is the control combo box variable.
Here is the error
C:\DEP\DEPDlg.cpp(18122) : error C2228: left of '.GetWindowTextA' must have class/struct/union type
Any help would be great thanks
|
|
|
|
|
CDialog1 is the name of the dialog class. To call a method of that class, you must have a variable of that class available.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
