|
Anonymous wrote:
it keeps throwing "Disk full while accessing C:\...\file" at me despite the fact that I have 50 GB of free space left on my computer.
Strange, since you are only writing 4 bytes.
fileWrite.Write (n_buffer, sizeof (n_buffer));
"sizeof (n_buffer)" returns the size of the pointer 'n_buffer'
(which is 4 bytes on a 32-bit system) not the size of the buffer.
Steve T
|
|
|
|
|
FlyingTinman wrote:
"sizeof (n_buffer)" returns the size of the pointer 'n_buffer'
n_buffer is a CString object, not a pointer. Your point about misusing sizeof is still valid, however.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Try:
CFile::modeCreate | CFile::modeWrite
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Ok, adding modeWrite got rid of the Disk Full error. Also, I didn't know that sizeof only gave the size of the pointer to the string, which would explain why I get gibberish in the file after adding modeWrite. However, n_buffer.GetLength() produces no output in the file, so that doesn't seem to be the correct option either. My guess is that it's not working because Windows 2000 and XP use unicode representation and each letter ends up being 2 bytes, so the actual sizeof is doubled? If so, what fix could I apply so that it would work with both: current and old versions of windows that used ANSI? And if my guess is completely unrelated to the actual problem, can anyone suggest what's actually causing this? Thanks.
|
|
|
|
|
Apparently the problem is with the file's encoding, and not with the OS. The original file spits out gibberish (I'm guessing it uses ANSI encoding), when I copy/paste all its contents into a new file, and run the exact same routine on it, the new output is fine. Is there a way to run a check on the file's encoding before it's processed?
|
|
|
|
|
I didn't realize you were storing a CString within a CStdioFile. Wouldn't WriteString be your best option?
<br />
file.WriteString(n_buffer);<br />
Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Jack Squirrel wrote:
Wouldn't WriteString be your best option?
Only if carriage return–linefeed pairs needed to be translated.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Anonymous wrote:
fileWrite.Write (n_buffer, sizeof (n_buffer));
If you are going to use Hungarian notation (I assume that was your attempt), at least use it correctly. Seeing n_buffer indicates to me an int or short type.
Try:
fileWrite.Write(n_buffer, n_buffer.GetLength() * sizeof(char)); CFile::Write() is expecting a byte count while CString::GetLength() returns a character count.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Yeah, I know I didn't use correct hungarian notation, what that n is meant to stand for is new buffer, because I have two of them. Also, what if the file uses a different encoding than the OS? How do I test that?
|
|
|
|
|
Anonymous wrote:
Also, what if the file uses a different encoding than the OS? How do I test that?
I'm not sure I follow. The OS is not concerned with how an application write to or reads from a file. Perhaps you should elaborate on your concern.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Well, the original file doesn't get processed right, it spits out blocks (gibberish) after being proccessed. However, copy/pasting its contents into a new file and processing new file results in correct output. My guess is that although I'm using Windows 2000, the machine that the file was created on used a different encoding than the one my OS uses when it creates a new file.
|
|
|
|
|
Since CStrings are TCHAR-capable, I would suggest changing the code to:
fileWrite.Write(n_buffer, n_buffer.GetLength() * sizeof(<code>TCHAR</code>));
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
I want to use SetTitle function but compiler gives that error "C2065 'SetTitle' : undeclared identifier.
How can i use this function.
|
|
|
|
|
I found a solution, but i guess it is not a good solution.
I have remove these form stdafx.h
#ifndef _WIN32_IE // Allow use of features specific to IE 4.0 or later.
#define _WIN32_IE 0x0400
// Change this to the appropriate value to target IE 5.0 or later.
#endif
i dont understand but it seems to work good.
|
|
|
|
|
If you look up the Win32 documentation for TTM_SETTITLE (which is called by SetTitle), it lists the requirements as:
Windows 2000, Windows NT 4.0 with Internet Explorer 5, Windows 98, Windows 95 with Internet Explorer 5.
Therefore you need to change the _WIN32_IE value so that it will target at least IE 5.
<br />
#ifndef _WIN32_IE // Allow use of features specific to IE 4.0 or later.<br />
#define _WIN32_IE 0x0400<br />
#endif<br />
to
<br />
#ifndef _WIN32_IE // Allow use of features specific to IE 4.0 or later.<br />
#define _WIN32_IE 0x0500<br />
#endif<br />
You can see all the various macros/constants here:
Using the Windows Headers
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
I have a console only application written entirely in standard, unmanaged C++. I'd like to build a GUI front end, but I've run up against a problem. Any method of making a GUI frontend (which will require two-way communication with the actual C++ program) requires converting the entire project to managed C++. This is not an option. It is also not an option to build the GUI in managed C++ and interface it with the normal C++. Unfortunately, all other methods (such as writting the GUI in C#, J#, or Visual Basic) allow only one way communication (C++ calling the GUI) and cannot allow the GUI to call C++ without managed wrappers and a large amount of dll wizardry. Again, using managed C++ in any form is not an option.
Anyone have any ideas? Building a straight GUI in Win32 non .net is too time consuming and difficult. One idea I was throwing around was writting the GUI in Java and it would communicate with the main app through the console, but I'm not sure how much of a speed hit this would cause.
|
|
|
|
|
Ummmmm... What about using MFC? Is that an option?
Not too time consuming, no 'managed c++' issues...
If your console application separated its data from its UI, you could build a local RPC server interface into your console application and then use local RPC to communicate with it from a GUI client.
|
|
|
|
|
I was under the impression MFC required the use of managed C++... if it doesn't, then its a strong possibility. Thanks for the suggestions, I'll look into both! If anyone has something else to add, please do so. Thanks again.
|
|
|
|
|
my project is on database in c++ and ado .
i wanna add gui features using MFC/SDK.
plz help its urgent
|
|
|
|
|
Having a strage time with a custom CWnd derived control in MFC. My OnPaint method never gets entered. I've got a message map:
BEGIN_MESSAGE_MAP(CGMeterCtrl, CWnd)<br />
ON_WM_PAINT()<br />
ON_WM_ERASEBKGND()<br />
END_MESSAGE_MAP()
And a handler:
void CGMeterCtrl::OnPaint()<br />
{<br />
...
And according to Spy++ when my control's in a dialog test app it recieves WM_PAINT messages in the right places. I can't figure out why OnPaint is never called.
Any tips?
|
|
|
|
|
Does anything show up at all?
This might be silly, but make sure your control has the WS_VISIBLE style set.
Maybe windows thinks it is not 'on' the screen? So you don't get any paint messages.
Also, make sure its coordinates are also visible, it is not offscreen or outside the coordinates of the window/dialog.
|
|
|
|
|
The control shows on the dialog, I changed the background colour & gave it a 3D border to make sure. It's stuck in the middle of my dialog and the borders don't go outside the dialog edges. Like I say, Spy++ shows WM_PAINT being sent to the control, my message handler just doesn't get called.
|
|
|
|
|
Did you also declare the paint handler in the header file?
// Generated message map functions
//{{AFX_MSG(CYourDialogClassNameHere)
...
afx_msg void OnPaint();
...
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
|
|
|
|
|
Sure did 
|
|
|
|
|
I am baffled.
Just some ideas off top of my head here:
Does the erase background message get called? This at least lets you know the parent-child relationship is set up okay.
Can you call Invalidate() and UpdateWindow() on your control to FORCE a paint message to it? Just to be sure the 'regular' paint messages are not masked out by something else, like maybe child rectangle clipping or some other wierdness in the parent window?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
