|
Hmm, thank you WalderMort
But still i am not sure about whether notification or message sending proceed first.
Which one is first making by OS.
Put msg to msg tail and then notify parent or notfy parent and put msg to tail.
Thansk again.
|
|
|
|
|
There is no notification for "a string was added to a combobox" because that's not something the user can do. There is a notification for "a button was clicked" because the user can click buttons, and your app needs to know when it happens.
|
|
|
|
|
ok
thank you Michael Dunn, i understand it.
Which one is doing first by OS for example for button click.
Notification or adding msg to msg queue?
|
|
|
|
|
The message is the notification.
|
|
|
|
|
For button message, I think you can just ignore the notification code of BN_CLICKED.
|
|
|
|
|
I have just started experimenting with drawing. The following code simply draws some nonsense to get an idea of how the commands work.
Question: In my code I define the rectangle. Is there a way to get the rectangle coordinates of a dialog object? Then assign them to MyRectangle ? Then draw in those coords? Then the drawing area could be moved around the dialog in the dialog editor.
CClientDC dc(this);<br />
CPen MyNewPen;<br />
MyNewPen.CreatePen(PS_SOLID,1, RGB(255,0,0)); <br />
CPen *pOriginalPen;<br />
pOriginalPen = dc.SelectObject(&MyNewPen);<br />
<br />
CRect MyRectangle(20, 10, 120, 110); <---can I get these coords for a dialog item?<br />
<br />
dc.MoveTo(100,100);<br />
dc.Ellipse(&MyRectangle);<br />
dc.LineTo(200,200);<br />
dc.SelectObject(pOriginalPen);
|
|
|
|
|
Have a look at GetWindowRect(), GetClientRect(), ClientToScreen() and ScreenToClient(). Also look at the CRect member functions, there are lots of functions there for manipulating the rectangle.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Hi guys,
I’m hoping that someone might be able to help with a problem I have porting some libraries from VC6.0 to compile in VC7/Visual Studio .NET 2003.
The Author of the libraries is unable to help, and it seems that the problem is with c++ standards conformance (related to mostly templates.)
I’ve stripped down part of the code to one of the lib’s, and made a small simple example ( Win32 console test app ) below to show the problem, and the error(s) the VC7 compiler gives when trying to compile it. I’ve never been that good getting my head round and using templates, so this is turning into a major headache for me to fix.
If anyone can help, i would really appreciate it.
Thanks.
#include "stdafx.h"
#include <iostream>
using namespace std;
namespace lang
{
template <class T> class NumberReader
{
public:
NumberReader();
int put( char ch );
const T& value() const;
bool valid() const;
};
template <> class NumberReader<double>
{
public:
NumberReader()
{m_state=STATE_INIT; m_valid=false;}
int put( char ch );
T value() const;
bool valid() const{return m_valid;}
private:
enum State
{
STATE_INIT,
STATE_SIGN,
STATE_BODY,
STATE_FRACTION,
STATE_EXP,
STATE_EXP_BODY,
STATE_EXP_FRACTION,
};
bool m_valid;
State m_state;
};
}
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
error C2146: syntax error : missing ';' before identifier 'value'
error C2501: 'lang::NumberReader<double>::T' : missing storage-class or type specifiers
warning C4183: 'value': missing return type; assumed to be a member function returning 'int'
|
|
|
|
|
The problem is here
template <> class NumberReader<double>
and then here
T value() const;
The template doesn't know anything about T. Perhaps you left out the
template < class T > class NumberReader<double>
when you modified it?
|
|
|
|
|
cobra999 wrote:
template <> class NumberReader<double>
{
public:
NumberReader()
{m_state=STATE_INIT; m_valid=false;}
int put( char ch );
T value() const;
bool valid() const{return m_valid;}
You must replace all occurences of "T" with "double" when you are specializing the template for the type double.
|
|
|
|
|
template<> class NumberReader<double> is a specialization of the NumberReader class and it has no idea what T is. Change the T to double and it should work just fine.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Thanks guys, @Billy Joel, cheers that worked
|
|
|
|
|
One of the major differences between C and C++ that really hits me is the memory allocation. In C there is malloc() , and free() , in C++ new and delete . Why is it that C has a whole bunch of other functions like calloc() , realloc() and _msize() ? The latter is what pains me today.
Most of you will say to use a vector , but in some instances this is not possible. For example I need to allocate space for a RGNDATA struct which is a little more than a simple array. Allocating the space is no problem, but how is it possible to later find out how much memory was allocated? In C a call to _msize() would do the job, but experience tells me not to mix C and C++ when it comes to memory.
Is there a way to do this other than storing the size when it was allocated?
|
|
|
|
|
The first question I have to ask is why, other than to allocate the memory in the first place, do you even need to know, or really care, what the size is?
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Maybe you noticed another thread a started a few lines down about a bug in my code, where I called delete on a pointer I shouldn't have. I have decided the best way to approach the problem is to copy the memory rather than return the pointer itself. Much the same as many of the standard api functions do. So I'm basicaly creating a function like:
GetRegionData( LPRGNDATA, DWORD dwSize )
And as you can guess, the first call with a NULL pointer should return the size required.
It's no big deal, I just added a new member to the class, but I was wondering if there was a similar method to _msize() in C.
|
|
|
|
|
WalderMort wrote: It's no big deal, I just added a new member to the class...
I suppose if it gets out of hand (you have so many LPRGNDATA/dwRgnSize pairs) you could write
a little wrapper class that encapsulates the pointer and the size.
|
|
|
|
|
I thought of that, in my instance though it's not really warrented. I did however try subclassing the RGNDATA struct adding a new DWORD dwSize member, but due to the layout of the origional struct the new member is overwritten as soon as the RECT's are written.
|
|
|
|
|
I have not done a lot of work with regions, but is that information not available in the RGNDATAHEADER?
Otherwise, I am not aware of such a function as I have never had the need for one.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
PJ Arends wrote: but is that information not available in the RGNDATAHEADER
no, the data header states the number of rectangles in the struct, from which the size can again be calculated, but not the size itself. Like I said though, it's no big deal.
|
|
|
|
|
Ok, so the data is there, just not in the convenient form that you would like to see.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
yeah. I was hoping for something like sizeof() which would guarantee the allocated size. Calculating it from the data within the struct could lead to problems if the data was deleted or incorrect.
And once again, your 'Image Viewer' is making my life easier I just re-coded a lot of my region creating functions only to find the output is not what I expected. My first thought was "$%^&# I calculated the rectangles wrong", so fire up the old viewer, and guess what, the regions are perfect. Without your work I would have spent all night tearing my functions apart trying to find the fault, at least now I know where not to look. Thankyou
|
|
|
|
|
WalderMort wrote: Thankyou
Hey, I am just glad that someone finds that little app useful.:->
WalderMort wrote: My first thought was "$%^&# I calculated the rectangles wrong", so fire up the old viewer, and guess what, the regions are perfect. Without your work I would have spent all night tearing my functions apart trying to find the fault, at least now I know where not to look.
And now you know exactly why I wrote it to begin with. Been there, done that
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Well I found the problem ( a region being inverted when it no longer needs to be ). I still say you should sell it, even if you sell the development rights, it's a great tool and I'm sure many coders would benefit from it.
|
|
|
|
|
You know the size when you do the alloc. If you need to keep that size around for later use, then you have to store it somewhere.
An alternative is to use a vector of bytes:
vector<BYTE> vec(1000);
RGNDATA* pData = (RGNDATA*) &vec[0];
vector<BYTE>::size_type cbyBuffer = vec.size();
|
|
|
|
|
WalderMort wrote: Why is it that C has a whole bunch of other functions like calloc(), realloc() and _msize()? The latter is what pains me today.
C is a pain
WalderMort wrote: Most of you will say to use a vector,
Yes...
WalderMort wrote: For example I need to allocate space for a RGNDATA struct which is a little more than a simple array. Allocating the space is no problem, but how is it possible to later find out how much memory was allocated? In C a call to _msize() would do the job, but experience tells me not to mix C and C++ when it comes to memory.
The way that classes like vector do it is to store the size in a variable, I am sure.
WalderMort wrote: Is there a way to do this other than storing the size when it was allocated?
There are tricks with sizeof that I've seen used, such as sizeof(x)/sizeof(char) for the size of a char array. But, I'd be inclined to use vector, the address of item [0] is the address of the whole array. Or, write your own class to handle it.
Christian Graus - C++ MVP
|
|
|
|