Which is how I use "upcast", to a "bigger" container, the derived class. Of course, that's just a convenience notation. The real idea is

Cast Derived to Base - OK
Cast Base to Derived - Bad

+5. Great explanation. For me too, I've been reversing upcast and downcast terms, didn't think of the diagram. Saw the obvious error in his example though.

The declaration

Miembro persona;

is the same as saying

Miembro persona();

(constructor with 0 arguments) but the only constructor you defined requires 3 arguments

Miembro(int a, int b, int c)

so the compiler cannot resolve the reference.

You know, some days I don't remember where my head is. Of course you can do it and, in fact, I do it all the time in certain apps. For example, if I have a "DO IT!" button, that usually creates a worker thread that does some stuff and updates a "log view" edit control in the main dialog. The GUI thread continues on and watches for the user clicking on "STOP DOING IT!". Meanwhile, the worker thread does a

TheDialog->m_editcontrol.SetText(logbuffer);

or something equivalent to update the subclassed edit window. Works just fine. I guess I forget this because the "SendMessage()" is buried in the SetText() function and not something I explicitly do but it is still "SendMessage()" from a thread that did not "own" or "create" the control. Oh well, must be getting old.

If the same .exe file runs on some W7 machines and not others, then the problem is clearly something environmental on the machines that fail. Check for missing DLLs on the failing machines. Or build your application with MFC and C RTL as static libraries and try it that way.

DavidCrow wrote:

For example, the secondary thread sends a "add item to the control" message (e.g., LB_ADDSTRING) to the primary thread

This is the scenario that's confused me from time to time. It is really legal for a thread to do a SendMessage() to a control (the target of the LB_ADDSTRING) that is owned by another thread? I thought that Windows checked "thread ownership" of the control and returned an error on the SendMessage(). If the "primary thread" is, as is implied in your reply, the UI thread, then the "secondary thread" should not be allowed access to the control. I've always used "PostMessage()" and used "user defined messages" to have secondary threads pass messages / commands to the primary thread for action. Since "PostMessage()" is just a queueing action, there is no deadlock (although you might not get the immediate feedback of a screen update). Does anyone have the definitive answer on "SendMessage and Control Owner Thread" question?

Good Lord, Man, it's only 4 lines of code, 2 of them are ASSERTs. If you have the code, use the debugger and step into the function and see why it's blowing up. There are only 2 possibilities in that code, either the current object is not instantiated as a window (ASSERT_VALID) or the arguments you passed (row, column) do not represent a valid view (bad "pane coordinates") This should be easy enough to debug, once you know what it's complaining about, you'll know what you did wrong.

Note that SendMessage() cannot be used to send messages to controls that were *not* created by the thread sending the message. See my answer to This Question[^]

Not true, I use PostMessage() to a CDialog based window all the time. Note that SendMessage() cannot be used to send messages to controls that were *not* created by the thread sending the message. See my answer to This Question[^]

After reading all the replies to this, the one thing that's clear is that you've never told anyone exactly where you are creating the file. All we know is that it's someplace on your C drive. Well, newer versions of windows (beyone XP) place restrictions on where you can create files on the system disk ( C: ) so we'll keep going in circles until you provide details beyond "fail" and "hidden place" and other obscure bits of information.

Context dude, gotta read comments in the context of the thread

The point is, C++ did *not* decommit the "char" data type nor pointers. std::string is *not* the only way to do string manipulation in C++. It may be the perferred way for some people but it's not the only way.

The point is, C++ did *not* decommit the "char" data type nor pointers. std::string is *not* the only way to do string manipulation in C++. It may be the perferred way for some people but it's not the only way.

Technically, to pick nits, it *is* C++ as C++ is a superset of C. What you are really saying is that it isn't "Object Oriented Programming" which is true, but it is still within the definition of C++.

mackel90 wrote:

i got a huge project which works nice in release build

You realize that the assertion is telling you that you are issuing Scroll Bar Functions to an object that is not realized as a window. That is, the fact that m_HWND is NULL means that you are trying to scroll a window that doesn't exist. I'm not sure of your definition of "working fine" but this ain't my definiton. You should fix these.

Dude, I'm sure *you* know what you're talking about but it's not coming through in your posts. You have 2 programs, a "Client" and a "Server" using pipes. You have a "System" where these two program are running. Where do you want this "persistent" object to live, in one program or the other or in the operating system (Windows)? What do you want this object for? Depending on what you are going to do with the object, some objects are better than others. Unless you are clear as to what you want it for and where it's to live, you will get some pretty unstatisfying suggestions, like "Open a file, that'll persist"

Nice idea

You didn't "solve" the problem, you only made the "symptoms" go away. Now you have empty functions overriding ones that may have done something useful, as you've discovered. If it can't find the functions in the library then: 1) you didn't list the library as an input to the linker (both debug and release) 2) you are feeding in the wrong library 3) they are not in the library You need to go back to the person / source that gave you the library and ask them about the contents and why you are having this particular problem. I'm going to stop offering suggestions on this one.

OK, this code is posted "out of context" (it simply starts with the "if" statement, not how you got there). A reasonable assumption given your problem statement is that this code is run as part of an "OnChar()" or other event *caused* by your holding a key down. If that's the case, and you want to convert this to code that runs in a loop, you need to address two things. 1) what event starts the "jumping"? 2) what event stops the "jumping"? Clearly, right now event 1) is you holding down a key, event 2) is when you let it go. Letting the key go is *not* an event, it's the absence of a key_down event. You'll need to figure out the "stop" event first.

I hate to ask a question that should have been asked first. What is the exact error message. Which "symbol" is unresolved, the one in the base class or the one in your derived class? If it's the former, then the problem is that your library is not included in the linker section as an additional library. If it's the latter, then the problem is in your code and the definition of the overridden members.