|
My apologies. There is a search box above, but here are some links:
http://www.codeproject.com/vcpp/stl/index.asp#General[^]
I was wrong, I've not done an article on iostreams. I will rectify that today. I do show how they are used in other articles though. The gist of it is this to read a file:
#include <fstream>
using std::ifstream;
ifstream a("c:\file.txt");
int i;
a >> i;
and this to write one
#include <fstream>
using std::ofstream;
ofstream a("c:\file.txt");
int i = 7;
a << i;
More to come later today, I promise.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
thanks.. would you know how to do it with a comma separated file?
Have you ever used the TextReader function in the namespce System:IO. I think it's only for text strings..
Thanks --
|
|
|
|
|
For that, I would have to modestly point you to my article: CDataFile[^] 
That should help. I will update it to write the file back out in the next release.
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Suppose I receive raw data from a source. This source already placed it in memory for me and I only know the raw data doesn't exceed 10 megabytes. It's running on a computer with 512MB RAM or more.. What is more efficient if I want to write this raw data to a file :
- Create a buffer of xxx bytes
- Write the 10 MB to file at once
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
What format do you want the data in? ASCII or just a proprietary serialization?
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
ASCII, actually it's always plain text (well, some Base64 encoding might be there but that's text after all  )
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
I'd say just write the whole thing at once and let the OS's caching code worry about how best to write it out to disk.
--Mike--
Friday's GoogleFight results: Britney Spears 2,190,000 - Erica Weichers 23 
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Thanks, Mike.. that was actually the answer I wanted to hear
--
Alex Marbus
www.marbus.net
But then again, I could be wrong.
|
|
|
|
|
Is there a good way to tell whether some process has a given file open.
I am writing an application that allows the user to open a file in an arbitrary external editor. I start the editor in a spawned process with P_NOWAIT or P_DETACH flags, and want to figure out whether the editor has closed the file. Since the user can arbitrarily choose the editor, I can't make any assumptions about DDE or similar calls to the editor to query the status of the file.
The user may close the file in the editor without closing the editor, so I can't simply check whether the given PID has exited.
Thus, my question is: given a PID (process id) and a filename (full path), is there a Win32 API method of determining whether the process PID currently has the given file open?
Thanks,
Jonathan
Why couldn't Science, in the long run, serve
As well as one's uncleared lunch-table or
Mme X en Culottes de Matador? James Merrill
|
|
|
|
|
You can test if a file is open by trying to open it for exclusive access with no sharing. It the file exists but the open fails, another process has opened it.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Cool! Elegant solution. Thanks.
|
|
|
|
|
I have a small but annoying problem I'm hoping someone here can help me with. I've built a small shell context menu extension dll. When my item is invoked from the menu, I create my dialog box with progress bars , set up the list of files and send them off to the dialog, which then processes them. The wierd behaviour starts when I have two shell windows ( My Computer windows ), and I run some files from each window at the same time. The underlying process is built so that the second dialog will sit waiting, ready to go, while the first one finishes - that part is ok. What is strange is that as the dialog in the first window is processing, and updating it's progress bars, the progress bars in the other dialog are also being updated.
Any clues? Thanks in advance for any help.
|
|
|
|
|
Using VC++ 6.0 and MFC
I am dynamically creating child windows in a derivative of CScrollView. This is working really well.
How can I save the child window which has the focus when another application is activated so that this can be restored when the focus is returned to my application.
Example is when user switches to Explorer then back to my app using the buttons in the start bar.
I have tried a few methods but they do not seem to behave consistently. Any suggestions will be very welcome.
Sara
|
|
|
|
|
Hi,
If I draw a rectangle on a dialog using this code it draws a nice rectangle with black frame on NT but nothing on 2000, any idea ?
CRect rect;
CClientDC dc (dlg); //get our device context
dlg->GetClientRect (&rect); //get the pointer to our window
CBrush brush (RGB (192,192,192));
dc.SelectObject(&brush);
dc.Rectangle(20,30,40,70);
|
|
|
|
|
How many Dialogs and stuff do you usually have before you start putting them into DLL's? Also, do you put more than just the dialogs into DLL's? When would I consider building a class as a DLL?
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
I think the main criteria for putting stuff in a DLL is its ability to share the content of the DLL.
or
If the data is rarely used, and your program would benefit from only loading the DLL when it is needed.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
So if my application is pretty much canned in one main class and no one else interfaces with it, forget the DLL? Except if I have some functions and classes which aren't used often, so put them away into the DLL to avoid the overhead when they are not in use...
I guess if you don't have an explicit reason for a DLL, you probably don't need one?
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Nitron wrote:
I guess if you don't have an explicit reason for a DLL, you probably don't need one?
Yep. I see applications that go over 2 MB in size. Alot of that is resources and images, but still your EXEs can get as large as you want.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Cool. Thx. Well, I had enough for one week... Have a good weekend!
Oh, I'll be sure to have a ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif) or for you! 
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
I just made my mainframe class inherite from another simple class ( standalone, class, does not inherite from anything else ), and I get these errors :
afx_msg void OnStandardToolBar(NMTOOLBAR* pnmh, LRESULT* plRes);
afx_msg void OnViewToolBar (NMTOOLBAR* pnmh, LRESULT* plRes);
...
ON_NOTIFY(TBN_DROPDOWN, ITB_STANDARD_TOOLBAR, OnStandardToolBar)
ON_NOTIFY(TBN_DROPDOWN, ITB_VIEW_TOOLBAR, OnViewToolBar)
...
D:\\MainFrm.cpp(287) : error C2440: 'type cast' : cannot convert from 'void (__thiscall CMainFrame::*)(struct tagNMTOOLBARA *,long *)' to 'void (__thiscall CCmdTarget::*)(struct tagNMHDR *,long *)'
Pointers to members have different representations; cannot cast between them
D:\\MainFrm.cpp(288) : error C2440: 'type cast' : cannot convert from 'void (__thiscall CMainFrame::*)(struct tagNMTOOLBARA *,long *)' to 'void (__thiscall CCmdTarget::*)(struct tagNMHDR *,long *)'
Pointers to members have different representations; cannot cast between them
I'm assuming it's name conflict somewhere ...
Any Ideas ?
Max
P.S. I hate fridays!
|
|
|
|
|
Maximilien wrote:
P.S. I hate fridays!
Well, I like Fridays myself -- it's the start of the weekend!
But anyway, your problem is not related to name conflicts. If you look at the error, it's expecting you to pass it a function with this signature:
void (__thiscall CCmdTarget::*)(struct tagNMHDR *,long *)
And you're passing it this:
void (__thiscall CMainFrame::*)(struct tagNMTOOLBARA *,long *)
I believe that changing the first parameter to be of type NMHDR (instead of NMTOOLBAR) should take care of the problem.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
even if it actually expect to have a NMTOOLBAR ?
I assume it's safe to do :
NMTOOLBAR* pnmh = (NMTOOLBAR* ) pNBHDR;
in the handler ?
anyway, seems to be working !
Thanks, now I can go home free as a bird !
Max.
|
|
|
|
|
Maximilien wrote:
I assume it's safe to do :
NMTOOLBAR* pnmh = (NMTOOLBAR* ) pNBHDR;
Not only is it safe, it's correct.  All the WM_NOTIFY structs have a NMHDR as their first member, think of it as inheritance for C.
--Mike--
Friday's GoogleFight results: Britney Spears 2,190,000 - Erica Weichers 23
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
How do I add Help File Functionality to my VC++ MDI application ? Please help
|
|
|
|
|
compile your help files using HTMLHelp Workshop, so that you got the *.chm ready. Then in your method to serve the help menu item, just add:
HWND hwnd = ::HtmlHelp(this->m_hWnd, szBuff, 0, HH_DISPLAY_TOPIC);
to display the help file.
remember to include the #include <htmlhelp.h>
and the library.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
