|
Hi,
Is there any code out there that shows how to make the first colomns of a list control
static. That is when a horizontal scroll is made, the first columns of the control stays
in view. I searched the net for some info, but could not find any.
tia.
|
|
|
|
|
No, you'll need something like a grid control to do that.
|
|
|
|
|
paper67 wrote: Is there any code out there that shows how to make the first colomns of a list control
static.
By Design ListCtrl doesn't provide you thsi property but you can achieve same by writing your algo after subclassing the ListControl to make First Item Always Fixed User Scroll. it is pretty much easy if you use GridControl!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief
|
|
|
|
|
See if the Extras section of this article is of any help.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
What about two CListCtrl overlapped? In the first one the parts that you dont want to loose, in the other the rest. The only problem is you have to keep the CListCtrl scroll sincronized (for the other direction).
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
I`m trying to create dialog for collecting customer information in an MFC application. The dialog contains a radio button to switch between customer type (private or company) when user changes the customer type I need some controls on the dialog to disapear and others to become visible... What would be your suggestions in getting this done?
|
|
|
|
|
you can make a control invisible by using:
this->GetDlgItem(IDC_XXXXX)->ShowWindow(SW_HIDE);
and visible by:
<br />
this->GetDlgItem(IDC_XXXXX)->ShowWindow(SW_SHOW);
where IDC_XXXXX is the ID of the control.
|
|
|
|
|
Also you can use ON_BN_CLICKED to get notifications when the user clicks a radio button.
In response to the notification(s) you can check if a radio button is "checked" using
CButton::GetCheck() or the BM_GETCHECK message.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
You can use of ShowWindow but Can you say how many controls you have on the forum?
|
|
|
|
|
Dear all
I add one library file (atapid.lib)to my project and compile it. but I get following error
atapid.lib(tapireq.obj) : fatal error LNK1202:
"D:\...\Debug\vc60.pdb" is missing debugging information for referencing module Error executing link.exe.
How can I overcome to this problem.
Regards
Monhi
|
|
|
|
|
Try rebuilding the entire application. i.e. Make a Full Recompile.
vc60.pdb is the 'Program Database' file and will be recreated when you will compile the app.
|
|
|
|
|
I am trying to understand how it is possible to transfer a binary file (CFile) through an open CSocket connection that uses CArchive/CSocketFile. Bellow is a sample of my actual code. The socket transfer is working because before transfering the file itself, I am serializing other objects. They are correctly received. But the CFile.serialize() method leads to the reception of an empty file.
Server part :
m_pFile = new CSocketFile(this);
m_pArchiveIn = new CArchive(m_pFile,CArchive::load);
m_pArchiveOut = new CArchive(m_pFile,CArchive::store);
...
CString strFileName = "C:\Toto.exe";
CFile sourceFile;
sourceFile.Open( strFileName, CFile::modeRead | CFile::typeBinary, &fe );
sourceFile.Serialize(*(m_pArchiveOut));
m_pSocket->m_pArchiveOut->Flush();
Client part :
m_pFile = new CSocketFile(this);
m_pArchiveIn = new CArchive(m_pFile,CArchive::load);
m_pArchiveOut = new CArchive(m_pFile,CArchive::store);
...
CString strFileName = "C:\Toto.exe";
CFile destFile;
destFile.Open( strFileName, CFile::modeCreate | CFile::modeWrite | CFile::typeBinary, &fe );
destFile.Serialize(*(m_pArchiveIn));
Any help would be appreciate. Thanks.
Guillaume.
|
|
|
|
|
It looks to me (and I could very well be wrong) that you're just serializing a CFile object,
not the contents of the file.
I would think you need to read chunks of bytes from the file and write them to the archive object
instead (read bytes from the archive and write to a file on the receiving end).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi Mark
Thanks for your answer.
This anyway sounds strange for me : when I am serializing an object like a CString or a CObList (using the .serialize method), it sends the content of the object. My first thought was that it should be the same for a CFile. What would be the goal of having a CFile object without content ? Strange ...
I will do it myself chunking the file or using the TransferFile API.
Thanks again.
Guillaume.
|
|
|
|
|
glemaire wrote: What would be the goal of having a CFile object without content ?
CFile is just a C++ wrapper around a file handle and provides methods for accessing the file
using the handle. Similar to the way a CWnd wraps an HWND and provides methods to access a window
through that HWND. The actual window data represented by the handle is in the system, not in your
CWnd object.
Hope that makes sense 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
I'm using WinInet APIs in async mode to upload files to server using HTTP protocol and "POST" request. As a matter of fact, I'm trying to simulate HTML form (multipart data) submit button.
I can successfully send file, but I have problem with making progress bar while uploading.
Here is code I'm using for sending:
while (dwReadLength != 0)
{
DWORD dwBytesSent = 0;
dwReadLength = fileLocal.Read(pBuffer, dwChunkLength);
if (dwReadLength != 0)
{
if (!InternetWriteFile(hInternetFile, pBuffer, dwReadLength, &dwBytesWritten))
{
if (::GetLastError() != ERROR_IO_PENDING)
{
strError.Format("CFileHostingHttpUpload::UploadFile::InternetWriteFile(2) = %d",
::GetLastError());
return FALSE;
}
WaitForSingleObject(hAsyncOp, INFINITE);
}
dwTotalRead+=dwBytesWritten;
pbUpload->SetPos(((double)dwTotalRead/dwTotalRequestLength)*100);
}
}
The problem is that my progress bar gets fully "progressed" in about 1-2 seconds, but file uploading is far slower (25kb/s upload speed). When I track transfer with net sniffer tool I can see that it takes about 10 seconds to upload 256 kb file, but progress bar gets fill almost instantly. I've tried about 6-7 different upload "loops" but all of them are giving almost same result.
InternetStatusCallback gives me this:
<br />
11:49:19 - Connected to server.<br />
11:49:19 - Sending request ...<br />
11:49:19 - Request sent: 186 bytes<br />
11:49:19 - Request complete.<br />
11:49:19 - Sending request ...<br />
11:49:19 - Request sent: 86 bytes<br />
11:49:19 - Sending request ...<br />
11:49:19 - Request sent: 4096 bytes<br />
...<br />
... (a lot of same status until the end of upload, no need to paste them all :))<br />
...<br />
11:49:19 - Sending request ...<br />
11:49:19 - Request sent: 4096 bytes<br />
11:49:19 - Sending request ...<br />
11:49:19 - Request sent: 4096 bytes<br />
11:49:19 - Request complete.<br />
11:49:19 - Sending request ...<br />
11:49:19 - Request sent: 802 bytes<br />
11:49:19 - Sending request ...<br />
11:49:19 - Request sent: 16 bytes<br />
11:49:19 - Receiving response ...<br />
11:49:29 - Response received: 1024 bytes<br />
11:49:29 - <br />
11:49:29 - Request complete.<br />
Does anybody have any kind of solution?
Best Regards and have a nice day!
|
|
|
|
|
I am trying to figure out how I can best move an existing mfc dialog app into a dll and then be able to launch it from a console based application when needed.
I understand the basics of dll importing / exporting and how to create and use a dll
I just want to know how do I get the app now insider a dll to initialize and show itself? basically the mfc is an observer type object and once created and made visible I can grab it's interface and start providing it data to output in the window.
Yours Truly, The One and Only!
|
|
|
|
|
Just write a console app to launch your existing app. There's no need to put it into a DLL.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Not going to work in my case.
This is going to be a part of a 3rd party tool I am working on, I rather that other developers link to the dll and be able to use it without any gui or mfc knowledge.
Yours Truly, The One and Only!
|
|
|
|
|
This may help - Kinds of DLLs[^]
Particularly the sections related to regular DLLs linked with MFC.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks Mark,  I already know about DLLs... I am just trying to contain all the MFC GUI logic inside a dll and then have a simple way to evoke the MFC Dialog based app I created with the Wizard. I would also like to be able to call this GUI from a console based app provided all the relevant mfc / windows definitions are included.
I know it's possible after all you can throw up a message box from a console app
Yours Truly, The One and Only!
|
|
|
|
|
Right - that's why I said look into those specific links.
MFC apps may require certain objects to exist and certain initialization to be done, depending on
how you're using it. That link is a starting point to those details.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
LOL are we going to play message Tag =P
I am familiar with that section of the DLL in MSDN, which basically is talking about the types of DLL, but I will take another look at it.
FYI: I was able to convert the mfc app into a dll package and have it build cleanly and spit out the dll and lib files for linking. I have also been able to link the mfc dll from my console based app and have it load the dll into the process space.
What do I need to do to create an instance of my MFC app which is deriver from CWinApp and have it initialized to be able to show my Dialog based window? All the logic I have that I need is inside the dialog based window class..so do I even need to worry about CWinApp, is there a way just to create a modeless window that has it's own message loop?
Yours Truly, The One and Only!
|
|
|
|
|
I'll rip the relevent portions for you:
"A regular DLL, statically linked to MFC, has the following requirements:
This type of DLL must instantiate a class derived from CWinApp.
This type of DLL uses the DllMain provided by MFC. Place all DLL-specific initialization code in
the InitInstance member function and termination code in ExitInstance as in a normal MFC
application.
Even though the term USRDLL is obsolete, you must still define "_USRDLL" on the compiler command
line. This definition determines which declarations is pulled in from the MFC header files"
"Regular DLLs must have a CWinApp-derived class and a single object of that application class, as
does an MFC application. However, the CWinApp object of the DLL does not have a main message
pump, as does the CWinApp object of an application.
Note that the CWinApp::Run mechanism does not apply to a DLL, because the application owns the
main message pump. If the DLL opens modeless dialogs or has a main frame window of its own, the
application's main message pump must call a routine exported by the DLL that in turn calls the
CWinApp::PreTranslateMessage member function of the DLL's application object."
"A regular DLL, dynamically linked to MFC has the following requirements:
These DLLs are compiled with _AFXDLL defined, just like an executable that is dynamically linked
to the MFC DLL. But _USRDLL is also defined, just like a regular DLL that is statically linked to
MFC.
This type of DLL must instantiate a CWinApp-derived class.
This type of DLL uses the DllMain provided by MFC. Place all DLL-specific initialization code in
the InitInstance member function and termination code in ExitInstance as in a normal MFC
application.
Because this kind of DLL uses the dynamic-link library version of MFC, you must explicitly set
the current module state to the one for the DLL. To do this, use the AFX_MANAGE_STATE macro at
the beginning of every function exported from the DLL.
Regular DLLs must have a CWinApp-derived class and a single object of that application class, as
does an MFC application. However, the CWinApp object of the DLL does not have a main message
pump, as does the CWinApp object of an application.
Note that the CWinApp::Run mechanism does not apply to a DLL, because the application owns the
main message pump. If your DLL brings up modeless dialogs or has a main frame window of its own,
your application's main message pump must call a DLL-exported routine that calls
CWinApp::PreTranslateMessage.
Place all DLL-specific initialization in the CWinApp::InitInstance member function as in a normal
MFC application. The CWinApp::ExitInstance member function of your CWinApp derived class is
called from the MFC provided DllMain function before the DLL is unloaded."
Is that better? 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
yes that is better  ... LOL
Hopefully I can display the dialog window without too much work!
Yours Truly, The One and Only!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
