|
You need to include the object module of header.cpp inside the build of your dll.
|
|
|
|
|
I don't know what does this mean? How do I do that?
|
|
|
|
|
...means your dll project should be building header.cpp... which produces an object file.
|
|
|
|
|
It is building header.cpp and it also produces an object file
|
|
|
|
|
If you actually compiled one as C and the other as C++ (or the other way around), you'll also have to deal with name mangling...
Standard C++[^]
If they're both C++, it's actually still possible to screw up the mangling, I believe Studio allows you to set the mangling mode to each file independently (haven't used Studio in a while though).
Decorated Names[^]
|
|
|
|
|
i think You need to include the object module of header.cpp inside the build of your dll.
|
|
|
|
|
|
Just in few words my question is next:
Is there a way to get current invalid region when CWnd gets WM_NCPAINT message (in OnNcPaint() handler)?
Details:
I have a main frame with few child dialogs placed on it. Dialogs have custom controls. Custom controls have specific non-client area and that area is drawn when the control gets WM_NCPAINT message.
Now I want to invalidate (redraw) only a small part of my main frame calling InvalidateRgn(&invalidRgn). If that invalid area overlaps with control's non-client area - WM_NCPAINT is sent to the control.
Code in control's OnNcPaint() is like this:
void CMyCtrl::OnNcPaint()
{
CWindowDC dc(this);
DoPaint(&dc);
...
}
And it paints over all window dc of the control. Whole non-client area is repainted, not only invalid region which I've passed when called InvalidateRgn(&invalidRgn).
That is a behaviour I want to get rid of. I need only invalid region to be repainted. My suggestion is that I need somehow to get current invalid region and select it before painting like
dc.SelectClipRgn(&invalidRgn)
So the question is can I do that? and if yes - how?
|
|
|
|
|
GetUpdateRect API call retrieves the smallest bounding rectangle that encloses the update region and does the same function as BeginPaint which is only for use in WM_PAINT calls.
Which answers your question ... My suggestion is that I need somehow to get current invalid region? ... and yes you can set it as a clip for your drawing if you want.
In vino veritas
modified 12-Jul-16 9:07am.
|
|
|
|
|
GetUpdateRect returns only client area coordinates that should be updated. I need whole control's invalid area including non-client parts.
Actually seems I've already find an answer: when Windows send WM_NCPAINT message it puts invalid region handle into wParam, but seems in coordinates relative to the desktop, - that's what I was looking for.
|
|
|
|
|
I´m sure there is a simple solution but it drives me crazy:
class A
{ virtual bool method M() };
class B : public A { .... }
class C1 : public B
{ virtual bool method M() override };
class C2 : public B
{ virtual bool method M() override };
class D
{
static bool DoSomething( A* ptr ) { ptr -> M(); }
}
Now I am working in a codepiece of C1 which calls D::DoDomething( )
C1::anymethod()
{
D::DoSomething( this );
}Ok, thats simple: C1::M() will be called because of the inheritance
But now I wanna have that D calls the M() of C1´s base A by typecasting the this ptr to a base:
C1::anymethod()
{
D::DoSomething( (A*)this );
}
but this will also call C1:M().
How can I tell the D::DoSomething function "If you use M1() then you have to call A::M1() "
with knowing that in DoSomething by the type of the ptr?
|
|
|
|
|
The simplest solution would be to create another non-virtual function in class A:
class A
{
bool method AM();
virtual bool method M() { return AM(); }
};
class D
{
static bool DoSomething( A* ptr ) { ptr ->AM(); }
};
|
|
|
|
|
oh , the example I have is more tricky:
D should call "the next M() of any parent above the child class C1"
Its vice versa to the virtual inheritance when you call the last one in the hierarchy ...
if I call
C1::anytest ()
{
B::M();
}
it goes "up" the hierarchy an calls the next found M();
in this case A::M()
But in class D´s DoSomething where I get a ptr to C1, or C2 ...
how can do it there?
|
|
|
|
|
Sorry, this was not clear from your initial question:
Quote: But now I wanna have that D calls the M() of C1´s base A
But you can do the same:
Implement a non-virtual function B::BM() which is called by the virtual function B::M() and so on. Then you can call the non-virtual functions AM(), BM(), and so on or the virtual M() function.
If you want to call the <code>M() function of the next upper class in the hierarchy, you need to know the real class of the passed argument during run-time. This requires that your classes support some kind of Run-time type information - Wikipedia, the free encyclopedia[^].
|
|
|
|
|
I think that here[^] you will find a solution, in fact, the same solution like Jochen said.
modified 11-Jul-16 8:10am.
|
|
|
|
|
Ah the joys of deep class hierarchy in C++ and OOP coding circa 1980-1990 
Probably too much danger in doing what should be done with that old code and using modern Composition over inheritance style.
It isn't going to be fun and C++ is going to fight you all the way as it will try to discourage that style.
Working with old code I feel your pain ... good luck.
In vino veritas
|
|
|
|
|
Hi,
i want develop one application which required the fast printing on dot matrix i saw one dos application it it's giving the printing very fast compared to windows
please suggest which technology should i prefer.
|
|
|
|
|
Print speed is a feature of the printer, not the operating system or programming language.
|
|
|
|
|
This is very general question 
Think about following topics:
- printer connection via: direct connection on parellel Centronics, ... WLAN network
- communication: whats between printer and programm code? direct commnication, printer driver, spooler, LAN network...
- how does operation system drivers communicate? do you use "Windows" printsystem which does Scaling, function mapping from window->draw to printer->draw?
the more comfortable you can code the slower the speed.
fastestway: use ASM and direct code the 8x8 bitmaps, send them to the printer, as we did in 1985
but think of: paper size, drawing, filling, fonts etc etc.
|
|
|
|
|
Sounds like you have the windows print driver sending the text out to the dot matrix printer in graphics form ... that means it will be printing the truetype fonts from windows. The old matrix printers are much faster if you just send the text in raw form and the printer uses it's internal font.
There is probably a setting on the windows print driver for the printer to turn the truetype font and print graphics output off.
You can also probably do it in code when you get the printer DC you should be able to set the printer capabilities before you start the print cycle in your code.
In vino veritas
|
|
|
|
|
Simple.
When printing, Windows transforms what you want to print into a graphic bitmap and then send the graphic to the dot matrix printer which can be very slow to process. This technique is used because anything that can be showed on screen can be printed.
With DOS, the app is directly sending commands to the printer, but is limited to printer internal fonts (Arial may be not available in the printer), sizes and other settings.
Another problem is that the app must know the commands of the printer.
So DOS os faster because it takes advantage of the printer internal capabilities. On windows, you can print in raw mode, but you are responsible of everything.
You can make windows print in the DOS fashion by installing the driver for for a Generic/Text Only printer. It will be fast but ugly.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Following problem:
I have a base class "B" in which there are some methods M1(),M2... Mn().
class B {
public
virtual void M1();
virtual void M2();
virtual void Mn();
};
now I have multiple derived classes:
class Ca1 : public B { .... };
class Ca2 : public B { .... };
class Can : public B { .... };
and again derived each from above
class Cb1 : public Ca1 { .... };
class Cb2 : public Ca2 { .... };
class Cbn : public Can { .... };
And at last another deriving step by
class Cc1 : public Cb1 { .... };
class Cc2 : public Cb2 { .... };
class Ccn : public Cb3 { .... };
Now the Question:
each of the derived last classes will override the methods M1, M2, M3 ...Mn... with the same functional content!
class Cc1 : public Cb1 {
virtual void M1() { } override;
virtual void M2() { } override;
...
virtual void M3() { } override;
};
class Cc2 : public Cb2 {
virtual void M1() { } override;
virtual void M2() { } override;
...
virtual void M3() { } override;
};
... this identical with identical code m1, m2 ... forall classes derived
Cc1, Cc2, ... Ccn!
How to best avoid to copy this M1, ... Mn block for method overriding into each derived class?
The existing code packed everthing into a macro and copied this into the classes
like
#define DRIVED_METHODS \
virtual void M1 { } \
and so on which results in horrible undebugable code!
Using multiple inheritance does not work:
class Cc1 : public Cb1, public CMpack
{};
class Mpack { void M1 {}; ... };
The only idea was to "map" each method to a class that collects these common methods
class Mcommon {
virtual void m_M1() { };
virtual void m_M2() {};
}
class Cc1 : public Mcommon
{
virtual void M1() { Mcommon::m_M1() ; } override
};I know that there must be a mistake in the whole design
but Im not allowed to change much because nobody knows why the anchestor did such a design and sideeffects on changing code may happen.
Have searched the web but best solution I got is the "Mapping"
parameters, return types in M1...Mn have been simplyfied to void, empty in the text above
|
|
|
|
|
Quote: each of the derived last classes will override the methods M1, M2, M3 ...Mn... with the same functional content!
What's the purpose of that?
|
|
|
|
|
some history I found out:
they had a collection of B*
typedef vector<B*> arrayB
then they stored Ca1* ... Can* in such a collection later they stored Cc1* ... Ccn* in such a collection because all derived from B ...
arrayB1 my_collection;
my_collection.push_back(Cc1* ... )
this is valid because the Cc´s are derived from B
B<--Cc1 , ...
if it is a B* the B::M1() was called
if it is a Ca1*, ...Can* the B::M1() was called
if it is a Cb1*, ...Cbn* the B::M1() was called
But if it is a Cc1*, ...Ccn* the overloaded Cc1::M1() etc. of the derived classes were called and do something different than the B::M1()
I dont know further what its good for, but its the way it was it was implemented
|
|
|
|
|
OK, I misunderstood your original question.
Could you possibly insert another derivation layer?
Why the 'mapping' solution is not appealing?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
