It takes however long you want it to take. If you really crack down on it, and you're already comfortable with at least one other Object-Oriented programming language, you could become proficient in only a week or two. If you've never programmed or have only programmed in a structure-oriented language, expect to spend a month or two (possibly more), assuming you're willing to put a good bit of work into it. If you're not wanting to put the effort into coding, you'll probably never become proficient.
Code a lot if you want to learn C++, or any language. Find a project you are interested in, and write it in C++. Or write some module/component for it, if it's not a new project. And of course, read a lot of other people's code, paying attention to style (that means learning to recognize good AND bad C++ style).
I have two zip files
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!
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.
3. there is a caption on the windows task bar button.
// 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"
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?
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.
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:
I need to do some clean-up before the application is closed, so I override the OnClose() function:
CDialog::OnClose(); // call base class handler<br/>
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?
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
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.
"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"
Ok... so first off you need to find what Library file contains those functions. I recommend google. Search for the unresolved external symbols you are having trouble with. I have to ask, what exactly is this program trying to do. I assume this is an MFC project so go try to find the libraries that MFC includes.
If this was no help then you might need to ask a professional. Like Michael Dunn
What I am trying to do is extract a file from a resource then write it into the system directory of windows. It compiles but it doesn't run correctly. I defined 1001 in resource.h and I included it also. I need help with this code here:
So where exactly are you facing problem in this code?
How are you going to know where the error occured as:
- Your code never calls GetLastError() to find out if a call to WIN32 Resource API succeeded or not.
- FindResource(), LockResource() and LoadResource() returns NULL in case of an error, you are not even performing any checks for that condition too.
- Are you sure the call to CreateFile() is succeeding, try using GetLastError() to know why it failed.
- You are not comparing the value of variable Written with the variable Size to know exactly if a call to WriteFile() succeeded or not.
Points regarding your code:
1. Please move UnlockResource() out of the if block.
2. It is not necessary for Win32-based applications to FreeResource. A resource is automatically freed when its module is unloaded.
GurmeetBTW, can Google help me search my lost pajamas?
In the .rc2 file, include the file you want to extract
ResourceName ResourceType "ResourceFilename"
To extract it:
ExtractFile("ResourceName", "ResourceType", pathname);
// note that hInstance is the instance off the DLL/exe which has the resourcebool ExtractFile(const CString& resourceID, const CString& resourceType, const CString& filename)
// need to extract the resource out into the filename suppliedbool bOK = true;
HANDLE hRes = ::LoadResource(hInstance, ::FindResource(hInstance, resourceID, resourceType));
if (hRes != INVALID_HANDLE_VALUE)
// we loaded it, not get the text from it
DWORD sizeOfResource = ::SizeofResource(hInstance, ::FindResource(hInstance, resourceID, resourceType));
char *lpRes = (char*)::LockResource(hRes);
if (file.Open(filename, CFile::modeCreate | CFile::modeWrite))
// write the resource out to the file
bOK = false;
// release the resource
Roger Allen - Sonork 100.10016 Strong Sad: I am sad I am flying Who is your favorite Strong?
I'm not too saavy in Visual C++ programming as most of my C/CPP has been in embedded platforms.
I'm working on a host application which is a VC++ window. Essentially, for this one particular window I want it to stay on top all the time. I have added some code that was given to me by someone who has done it in another application before, but it does not seem to be working in mine. Can anyone help?
Here is what I have:
CWnd appWnd; // the application CWnd
CWnd *pAppWnd; // a pointer to CWnd
pAppWnd = & appWnd;
pAppWnd = AfxGetMainWnd();
if (NULL != pAppWnd)
HWND appHandle; // window handle
appHandle = pAppWnd->GetSafeHwnd();
if (NULL != appHandle)
targetObj.m_pAppWnd = pAppWnd;
// Cause window to stay on top
targetObj.m_bWindowStayOnTop = TRUE;
targetObj is another class which is essentially being called by this (no "gui" elements in that class) and in that class, inside of a loop that he is in, I have this part:
// Used to keep parent window (test module) on topif (TRUE == this->m_bWindowStayOnTop)
BOOL bReturn = FALSE;
if (NULL != this->m_pAppWnd)
bReturn = this->m_pAppWnd->SetForegroundWindow();
It seems that the return from SetForegroundWindow() is 0 which means it is failing. But I don't know why! Any ideas?
There are only 10 types of people in this world....those that understand binary, and those that do not.
If that works, I am a superman, seeing as I've done nothing like this for years. It's damn close though. setwindowpos takes as it's first parameter a value that allows you to make a window move to the top or bottom, or make it topmost (i.e. top and stay there ). You pass whatever you like for the position and size, and use flags to make them irrelevant.
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder