|
thanks very much for explaination
I still have some questions regarding your reply:
1. you mentioned that ATL is lightweight whereas MFC is heavyweight. however the concepts here are still too abstract to me, could you give some vivd examples or comparasions to elabrate the difference between "light" and "heavy"?
2. ATL stands for Active Template Library, so does that means ATL is a collection of templates? in other words, are the ways of encapsulation different between ATL and MFC? I have tried to do some windows programming using MFC, and I feel it is not so convient. I don't think the encapsulation of MFC is good enough, am I right?
3. You also mentioned MFC's power is fading, so who is its successor? the window form class provided by .NET?
4. I also come cross some other terms like STL and WTL, what are they?
Thank you very much for your time
|
|
|
|
|
torrentmoon wrote:
1. you mentioned that ATL is lightweight whereas MFC is heavyweight. however the concepts here are still too abstract to me, could you give some vivd examples or comparasions to elabrate the difference between "light" and "heavy"?
Since ATL is built on using templates, there is no need for a big and quite bloated DLL/LIB to be linked in. Since templates aren't really "code" until instantiated, most of ATL will not be included in your application when compiled. Only the parts which you've instantiated is included. This "optimization" is only available during compilation, thus you can't peel away the unused parts in MFC since you link against it.
MFC also contains a massive amount of code including pretty much everything from file handling to active x controls. So there's a lot of bits to carry around - whether you like it or not!
ATL on the other hand basically just cover COM related things and windowing. It follows the UNIX principle: do only a few things; but do it well.
torrentmoon wrote:
2. ATL stands for Active Template Library, so does that means ATL is a collection of templates?
Yes, and no. There are C++ templates and there are functions. ATL uses C++ templates quite heavily to solve things quite elegantly (IMHO).
torrentmoon wrote:
3. You also mentioned MFC's power is fading, so who is its successor? the window form class provided by .NET?
Does anybody really know yet? Surely it'll be based on .NET, but I'm sure it'll look different than Windows Form as of today.
torrentmoon wrote:
4. I also come cross some other terms like STL and WTL, what are they?
STL = Standard Template Library - a container/algorithm library which is defined in the C++ standard. Most C++ compilers ship a version of it (either they ship a version based on the old version developed at HP or a version based on the newer developed at SGI).
WTL = Windows Template Library - an extension of the ATL windowing model. Looks like a reiteration of MFC at a first glance, but is VERY different under the hood. ATL/WTL has a cleaner design than MFC, IMHO. It produces very lean and mean code, and offers a great flexibility for customization. See the WTL section of Code Project, and don't forget to check out Michael Dunns guide to WTL.
--
Watcha' gonna do, when Hulkamania runs wild on you!?
|
|
|
|
|
When I invoke a web service's method which return a lump of complicated array , I fount the memory alloced by proxy class can't be freed automatically.I don't sure if I missed at some important place,and the method I used to Invoke the Web Service is absolutely standard.
this is c# WebService code ：
____________________
public struct MacAddr
{
public byte ma_1;
public byte ma_2;
public byte ma_3;
public byte ma_4;
public byte ma_5;
public byte ma_6;
};
public struct PortList
{
public System.Int16 port_num;
public System.Int32[] ipList;
public MacAddr[] macList;
};
...........
[WebMethod]
public PortList[] GetPortList()
{
const int plSize=10;
PortList[] pls=new PortList[plSize];
for(int i=0;i
|
|
|
|
|
//and the source code like this:
for(int i=0;i<10000;i++)
{
ATLSOAP_BLOB bb;
Service1::CService1 sv;
Service1::PortList *pPl;
sv.GetBuffer(&bb);
HRESULT hr=sv.GetPortList(&pPl,&nSize);
}
//any problem???
|
|
|
|
|
Hello all.
I am wondering what the best way to display a progress bar to show the progress of file copying. Let's say I want to copy 500 files. Most of them are big, but some of them are small. I do not want the progress bar to reflect the # of files that are currently copied, but I want it to reflect the number of bytes actually copied. (Lets say 450 of those files are really small, and 50 of them are really huge, taking a long time to copy. If I did it this way, the progress bar would move very fast to about 75%, then go very slowly for the last 25%). If I did it by way of total bytes copied vs. total bytes, then it would be truely accurate.
I am wondering what the best way is to do this? It appears that the progress bar SetRange() can only take a short value (up to 32,767), so I think that I would have to do some math during the file copying routines to figure out which value to set the bar at.
Any pointers in the right direction would be very much appreciated.
Shultas
|
|
|
|
|
u could calc the % of the total copy size that each file represents and inc the progress bar by that amount after it has copied
"there is no spoon"
biz stuff about me
|
|
|
|
|
hmmm, you seem to be having a small problem with progress bars;)
If I were writing the program, I think I would use two progress bars, one that shows the progress of the total number of files to copy, and another one to show the progress of each individual file (similiar to what is shown on some instalation programs)
The first bar is easy, set the range to the total number of files, and step it after each file is copied.
For the second bar, I would use GetClientRect() to get the length of progress bar, and use that length as the range. Then get the file size, divide the size by the range to get the step interval, and step the progress bar after every interval bytes has been copied. Just be sure to reset the bar's position to zero after every file.
If you want only one bar, then you would have to get the total size of all the files, and divide that size by the bar's length to get the step interval.
This way, you only step the progress bar when it will actually have something to draw, greatly speeding up the program, whiloe giving accurate progress indications.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
My problem is that I read too much! I am just starting out with VC++, so I decided to build an application that would benefit myself, and this way I could educate myself at the same time. I built the entire application already in VB. (Minus the progress bar thingie). I've got the program to pretty much do what I want, but then I'll read a post about this or that and say to myself "Gee, I wonder how that works". As soon as that happens, I want to do it for myself immediately. (Even though I'm a beginner, I will endeavor to do whatever my mind says "That would be cool")
So, just to be sure that I am doing this in the right way.
I figure out the names of the files I want to copy. I then use a file handle along with GetFileSize() to get the actual byte size of each file. Meanwhile, I'm adding to a "double" variable with the totalByteSize.
Then, while I am copying the files, I use a file handle again and determine the file size of the current file. Do my math stuff, and update the progress bar after the copy is complete.
The reason why I ask about the method is that say there is a way to do this without all of those steps. I don't want to have a bunch of un-necessary steps in my code which does the same things over and over, thus slowing down the program, simply because I want it to look right. I'm thinking that using GetFileSize for each of the files would probably not slow the program down all that much, what do you think?
Thanks again!
|
|
|
|
|
Oh yes. One other question 
I do really like the idea for displaying the progress bar for the status of each file copied as well.
I looked into the CopyFile() methods. It appears that this method just fires off in the background and does the copy, so I'm thinking that maybe CopyFile() would not be a sensible use for me in this program.
Do you suggest that I build the file copy routines in straight C, in order to get the actual number of bytes that are currently copied, or is there an easier way?
By the way: I really appreciate you taking the time to help me out!
Shultas
|
|
|
|
|
shultas wrote:
Do you suggest that I build the file copy routines in straight C, in order to get the actual number of bytes that are currently copied, or is there an easier way?
If you want to show the progress of the copy as it is being copied, then yes, write your own copy routine. If you are using MFC you could use the CFile::Read() and CFile::Write() to move large blocks of data in one step. I wouldn't try to do the copy one byte at a time. If you are not using MFC, then fread() and fwrite(), or _read() and _write() would be the functions to use.
shultas wrote:
By the way: I really appreciate you taking the time to help me out!
No problem, I am currently sitting here contemplating my belly button so I might as well have something better to do
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
One other question pertaining to this progressbar. On MSDN, it lists some members of the CProgressCtrl class. One of those methods is "SetBkColor()". Of course, when trying to use it, it is telling me that it is not a member of the class. However, the MSDN site is showing it as a member method.
I have downloaded the SDK as well, and the file that it is referring to is "afxcmn.h". I looked in that header file, and sure enough that method is not in there. It's not in there under the "vc98/mfc/include/afxcmn.h" nor is that method in the header file in the afxcmn.h that is included in the SDK. (It's in the win64 dir, there's no other afxcmn.h file in any other directory). I went to the SDK download site to ensure that I had the latest version, and everything is up to date.
Any ideas why this is giving me grief?
Thanks
|
|
|
|
|
AFAIK SetBkColor() is new to MFC7 and can be found in afxcmn.inl
_AFXCMN_INLINE COLORREF CProgressCtrl::SetBkColor(COLORREF clrNew)
{ ASSERT(::IsWindow(m_hWnd)); return (COLORREF) ::SendMessage(m_hWnd, PBM_SETBKCOLOR, 0, (LPARAM) clrNew); }A work around is send the PBM_SETBKCOLOR message to the control yourself. PBM_SETBKCOLOR is defined in commctrl.h. Just remember that PBM_SETBKCOLOR is wrapped in an #if (_WIN32_IE >= 0X300) block.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Hello again all.
I am wondering what the best way for me to read a text file would be in Visual C++ 6.0. I have some files (like log files) that are one line a piece, ending with a CR or CR/LF at the end of each line. Currently, I am using c, fopen/fgets. I have a couple of issues with the way I am doing it now.
1. I don't know the function to get the size of the file. I've got 4 books sitting around (and a couple normal C books), and have looked on the WEB and MSDN for hours trying to find the function to do this, with no avail  The reason I need the filesize is because I am using a progress bar to let the user know the status. Currently, I am fread() over and over until the end of the file, counting each time I do that, then setting that as the max for the progress bar, then fseek() to the beginning of the file, and begin the normal processing (that takes a little time). So, the crap thing about this is that it literally has to read the file two times to do it's thing in order for me to get the progress bar going right. (This is because I don't know how to get the size of the file!)
2. I was trying to determine the size of the file during the while (fgets...!=NULL) {} loop. I was reading into variable "buf". I tried using strlen(buf) and adding that to a variable "totalBytes", but it is always off. It appears as though the CR/LF is throwing off the strlen.
So I am wondering first off, how would I determine the size of the file. And, while processing (with fgets() ), how do I know exactly how many bytes I've read in. Also, I am wondering if it is wiser to use CFile or something of that nature to read the file (if it would be faster?) Currently, it appears that the routines that I've tested out in CFile read the file in big chunks, not one line at a time like fgets(), so it makes it a little bit harder for me to parse the data. I would prefer to read one line at a time, this way I don't have to make these routines that have to save data over for the next pass in order to parse correctly.
Any help would be appreciated. I'm just starting out in VC++ and doing pretty much everything by reading all the text's on this site, plus a couple of books that I picked up, and MSDN's site. Lots and lots of searching. Most of the time I find what I need but sometimes a simple little thing like this (I did a lot of C programming in the past, but I just forgot most of the functions) takes a long time for me to find out!
Thanks all!
|
|
|
|
|
you can use GetFileSize() to get the size of a file, but the size is limited to what can be stored in a DWORD. It should be plenty good for text files though.
I prefer to use _lseeki64() to find the file size. It returns the offset that you are at in the file after a seek, so just seek to the end of the file and it will return the file size.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
hi!
u use CStdioFile which is a derived class of CFile. this class has
BOOL ReadString(CString str) ; function, which reads one line per call. u can refer them in MSDN. This should certainly help u. Similarly u have WriteString also, which writes one line each time. i think File size was already answered. CString class has so many functions which will be useful for u to find some delimiter and many other operations...
when going gets tough the tough gets going
|
|
|
|
|
Hi Buddies Please Tell me is there API or any Class which can get all files from a Folder ???.
|
|
|
|
|
CFileFind, FindFirstFile() & FindNextFile()
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
CFileFind
-Steven Hicks
CPACodeProjectAddict
|
|
|
|
|
How can I know the name of functions & its Parameters of Unknoun DLL file ?
Iman Ghasrfakhri
|
|
|
|
|
One solution is to win32 system program such as dumpbin.
c:\winnt\system32\dumpbin -exports unknown.dll
Kuphryn
|
|
|
|
|
functions: use Dependency Walker
parameters: you can't, unless you have a header-file with the function declarations
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Greg S. wrote:
parameters: you can't, unless you have a header-file with the function declarations
You can dissasemble the function and find the parameters it accepts  . Surely it will be a last resort, but if you can't get the function spec...
"semper aliquid haeret", Bacon.
-- Sebastián.
|
|
|
|
|
Hello all.
I am just playing around with Visual C++ 6.0 lately. I have simple code right now and all it does is read a 350K text file (with fgets) and looks for certain strings in that file and adds them to a listbox.
I noticed that when I run the program (without a progressbar) it takes about ~1 second to complete. However, as soon as I implement the progressbar, it takes about 3 seconds to complete for a non-smooth bar, and about 10 seconds to complete for a smooth bar.
I've tried two methods of updating the progressbar. The first was I just use SetPos() so I tried using SetStep() and StepIt(). Both of these methods dramatically slow the program down. If I take comment out the SetPos()/StepIt() methods and run the program again, it is blazing fast.
I am wondering if anyone knows how I can somehow speed up this process or maybe I am doing something wrong which is causing it to run slower, or is that just the nature of using a progress bar? I really want to have a progressbar in there for the bigger files that I am going to read, just because it looks cool. But in my program, it will eventually read 100's of files and parse through them, so the 5 seconds here and there will really matter. Any ideas on how to speed this up would be appreciated!
Shultas
|
|
|
|
|
Any drawing that is done on the screen will slow a program down, so I would think the best way to speed the program up is to update the progress bar less often, step it every 100K instead of every 10K so your 350K file would only redraw the progress bar 4 times instead of 36 times.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
In all honesty, at first I thought that this method would make the progress bar look somewhat "choppy", but I gave it a try anyways.
PERFECT results!
I did a check of how many times the While() loop was getting executed. Over 39,000 times. So I guess you could say that 39,000 calls to the SetPos would indeed slow the program down  .... I just put a lil helper variable in there and called it every 2,000 passes and it blazes perfectly fast just like it did when there was no progress bar at all.
Thanks very much for your help. Just a dumb little thing like that I spent a solid hour trying to figure out what the problem was! I guess if you call SetPos(1000) ... SetPos(1500) ... SetPos(2000), out of 39000 tries, between 1000-1300 is the same bar (meaning the progress bar never gets updated to add another bar to it between those numbers), but when you call SetPos() it appears that it still takes some processor time (even though the bar never physically changes).
Thanks again!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
