|
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?
|
|
|
|
|
Seems OnEraseBkgnd isn't being called either!
Calling Invalidate() and UpdateWindow() cause WM_PAINT messages to be show up in Spy++ they always have an hdc 00000000.
|
|
|
|
|
Do you have a static control or some other control on the resource dialog template that this 'custom control' will override?
If that is the case, then you need to also make sure you have 'subclassed' the instance of your MFC custom control so that it is 'attached' to the 'real window' of the control from the dialog template. If not, then in the OnInitDialog function you must 'create' the 'real' window for the custom control to use.
For example, suppose you already place a static frame control onto the dialog template with control identifier IDC_MYCSTMCTRL, and in the header file you have declared an instance of your custom control:
CMyCustomControl m_MyCustomControl1;
Then in the OnInitDialog you can call
m_MyCustomControl1.SubclassDlgItem(IDC_MYCSTMCTRL, this);
Which should attach the CWnd control instance to the 'real' window created from the dialog template.
If this were done by the ClassWizard, and placed into the DoDataExchange, it might look something like this:
DDX_Control(pDX, IDC_MYCSTMCTRL, m_MyCustomControl1);
|
|
|
|
|
That's it! There was a typo in my DDX_Control line, i.e. it was accessing a wrongly numbered IDC_CUSTOMx control, one which existed in resource.h but wasn't in my main dialog.
I'm now getting WM_PAINT etc. messages and I'm getting called at the right place.
Cheers!
|
|
|
|
|
phaderunner wrote:
My OnPaint method never gets entered.
How are you verifying this?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
TRACE at the entry point to the function and Spy++ looking at the control. Seeing if WM_PAINT messages in Spy++ correspond with TRACE outputs in the debugger.
|
|
|
|
|
Hi,
I have an activeX control which is displayed in the Internet Explorer via the object tag. Now, as you probably know, you can pass parameters to the activeX control by using the param tag.
My question now is, how do I get these parameters in my activeX control.
I read about IPropertyBag, but didn't find a good example on how to implement that. I even don't know whether this is the right way to get the parameters.
Does anyone know how to realize that? 
I hope so.
Thx in advance,
mimmi511
|
|
|
|
|
hiho@ll
is it possible to make a MFC bho which could use MFC controls?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
