I'm looking for a way to do the following:

class BaseClass
{
  public enum Action
  {
    NO_ACTION
  }

  protected virtual bool ValidateAction(Action a)
  {
   return true;
  }
}

class DerivedClass : BaseClass
{
  public new enum Action
  {
    ACTION1,
    ACTION2
  }

  protected override bool ValidateAction(Action a)
  {
    //... validate Action ...
  }
}

The above doesn't work because by declaring my enum Action as new in the derived class I've created a totally new type; thus the compiler complains that I shouldn't be trying to override ValidateAction in DerivedClass. Basically I want to avoid having to use protected bool ValidateAction(int) as my function prototype, thereby avoiding having to cast my enum values to ints all the time to make the call to ValidateAction. Also, this would allow me to call ValidateAction from BaseClass and be sure that my virtual method in DerivedClass gets called. Is there an obvious way of doing this that I am missing? Deriving from System.Enum to create an Action base class would do the trick, but I've read somewhere that this is poor practice. Any other suggestions?

I'm looking for an advanced grid control and have yet to turn up anything that quite fits my needs. I need something like an Excel sheet where I can cut/paste multiple rows/columns of data and be able to post all of this data back to the server. Everything I have turned up so far only allows editing of existing data, one line at a time. I've been looking into Office Web Components, and the Spreadsheet component would be great if I could just post the data in the sheet back to the server. It seems that the dataflow for these components is meant to be from server to client only. Can anyone around here point me in the direction of something like this, or give some pointers for creating such a control?

It really depends on the architechture of each of the machines -- they might both be Little Endian, Big Endian, or a combination of the two. That is to say, you might not need to swap the bytes at all -- doing so could be what's giving you trouble. If at all possible, try using the ntohs() and ntohl() functions to ensure you get your data correctly on any architecture. --Dean

Your error is because you aren't calling insert properly. I would guess (though it's hard to tell from your code) that you will want to try m_SplFileInfoMap.insert(make_pair(f_crstrUserID, l_SplFileTSInfoList)); --Dean

Check out this link for a reference to the API. To answer your question, if you create the socket with the SOCK_STREAM flag, then the TCP will be used and you will not lose any data since TCP is a reliable transport. However, if you want a potential speed-up in send times (at the risk of losing data), create the socket with the SOCK_DGRAM flag to create a UDP connection. The Send function takes data in the form of a void* (see above link for further reference). --Dean

I've noticed the same thing too. This is just a guess, but I think it's probably fine if the .lib file isn't updated. Basically the .lib file provides the interface for the DLL that you will link against in some other program. So, if you just update the implementation (rather than the function signatures) there is no reason to update the lib file, because the interface to the DLL remains the same. Again, I'm not 100% sure about that so someone correct me if I'm wrong, but I think you'll be fine linking against the .lib file even if it's not updated. --Dean

I've noticed in VS.NET 2003 when you use the app-wizard to generate a new C++ class, the header of the new class begins with #pragma once rather than and #ifndef, #define pair. Anyone know if there is a way to make it go back to using the #ifndef instead? #pragma once is fine for VS.NET, but when I want to port code to Linux, GCC always complains that it is obsolete.

Yes, I agree -- it's quick, dirty, ugly... I get the feeling though that going into something like templates would not have been understood if the above could not have been done without help from this board (no offense meant to anyone). I try to approach these things from the standpoint that a less elegant but easier to understand solution might better serve beginners. Then, at a later time, the better way to do something can be learned when the supporting knowledge is available. A fine line has to be drawn however, as the easy code might be a terrible way to do things. I suppose I should have added a disclaimer saying that there are better ways of doing things. With that said, I hadn't even thought about templates at the time :-O --Dean

Yes that would work, but once inside your function, you have to know what type of array has been passed. You could do something like this:

enum TYPES
{
  CHAR,
  DOUBLE,
  INT,
  ...other types...
};

void myFunc(void* data, int data_type)
{
  switch (data_type)
  {
   case CHAR: char* carray = (char*)data;
    .... do stuff
    break;

   case DOUBLE: double* darray = (double*)data;
   ...etc.
  }

  ...
}

You will probably also want to add a size parameter to myFunc as well, unless all your arrays will be a fixed size. --Dean

Here's your problem: In CParticleEngine::init(int nParticles) you have the following line: CParticle *m_pParticles = new CParticle[nParticles]; Change it to m_pParticles = new CParticle[nParticles]; and your code will work. By declaring the m_pParticles variable again in the init() function, you have made a new variable that only has scope in the init() function, and happens to be named the same as your member variable m_pParticles. Thus the member variable never gets assigned, and you (rightfully) get memory errors when you later try and delete it. --Dean

Could you post your code?

And don't forget to call delete on the pointers when you are done with the arrays, i.e.delete []signal_str; delete []data_index_ptr; delete []data_ptr;
-Dean

It removes clutter for one. Your header should be as clean as possible. Think of it as a reference for the functions that are contained in the class. If you can't remember how to call a function, you open up the header and find the prototype -- all that extra code in the file makes that task more difficult. The other (more important) reason for separating the two is known as "separating interface from implementation". Say you write a class and someone else wants to use it later on. They don't need to know how your class works -- only that it does the job you say it will. It keeps things simple for everyone -- it's basically another layer of abstraction. Plus, if you don't want anyone to see your source code for whatever reason, you can give them the header file and a compiled library to link against and they won't be able to tell how you did what you did with your class (at least not without a bit of extra work.) Then if you change your implementation later on (say for instance you find a faster algorithm for one of your functions) all you have to do is compile a new version of your code library and give it to your users. Then rather than having to recompile their whole program, your users only need to relink their application to your new library rather than recompiling their whole program. Hope that all makes sense. --Dean

What about writing a quick subclass of CArray that defines operator= and simply calls CArray::Copy()? That would still be compatible with your other class that just use CArray. --Dean

johnstonsk wrote: Should I create the function in the rfmAccess.h or should I create another *.cpp file and do it in there? Technically you could do either, but most of the time you will want to create a .cpp file corresponding to your .h file and define the function there. johnstonsk wrote: Do I have to create a prototype or can I just finish the function in the rfmAccess.h file See answer above. Small technical point: what you have in the header file already *is* the prototype. johnstonsk wrote: Am I calling the function correctly? If you are calling the function via a pointer, then you'll want to use lpRFMAccess->openCard("////.//RFM1");. If you are calling the function from an object you'll want to use oRFMAccess.openCard("////.//RFM1");. There are some other problems with your code above: When you define a pointer to the RFMAccess class, you need to give it a valid name. You have written RFMAccess *RFMAccess; -- give the pointer a name other than the class name like this : RFMAccess *lpRFMAccess; Also, when you use a pointer, make sure it is valid. The way you have your code, the pointer is never made to point to a valid RFMAccess object, thus trying to call a function via your pointer will probably crash your program. --Dean

I've had the same problem before (just dealt with it today in fact). The little boxes you see are non-printing ascii characters. When I ran into the problem, the char was decimal 26, hex 1A. You are reading a binary file as a text file, and that's why you are having a problem. If you read the file as binary, you won't have the EOF problem, you'll just have to change your code a little bit. --Dean

Check out this page -- shows a better way to get your random numbers. When you use modular arithmetic, you focus on the low-order bits that aren't as "random" as the high-order ones. The page shows many examples of how to get a random number (int or floating point) in a given range. --Dean

If you are just writing a simple console app, you can use argv[0]. --Dean

I don't know if this was the case in VS6 (since I haven't used it in a while), but I have noticed that VS.Net refuses to give the popup if you have a syntax issue preceding the code you are currently typing. I wouldn't really call that a bug though. Now that I've noticed that it happens, when the box doesn't popup I start looking for a missing brace or semi-colon, etc. Kind of helpful in a way. I know it doesn't really help you with your problem, but just something to look out for. --Dean

What you usually do is something like the following:

UINT CMyClass::ThreadFunc(LPVOID p) //this is your static func
{
CMyClass* pMyClass = (CMyClass*)p;

p->SomeNonStaticFunc(); //access non-static member functions
p->DataMember = 0; //access non-static member data
...
return 0; //return your thread exit code
}

void CMyClass::SomeFunc()
{
AfxBeginThread(ThreadFunc, this); //start your thread function
}

--Dean