|
 This is very confusing and not specific enough!
The assersions can be eliminated by testing the value that caused the assertion before calling the function (how you handle that is up to you).
If you are dealing with still images of the video data then you may be able to use CxImage (at CP), which converts the supported images to bitmap images (limits the image data you can manipulate, but only one dialog required).
I'm not sure if this helped, but it's better than nothing.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Hey there...
Hoping someone might be able to shed some light on an issue I am having while resizing windows. I've been banging my head against the wall for a week now and quite frankly, am out of ideas.
The main concept of what I am doing: I have a main window and three child windows. I essentially need to redraw the children over various parts of the main window. I do this during the main window's WM_SIZE.
ChildA and ChildB are drawn at start up and work perfectly, no issues. I calculate client_x and client_y from the lParam variable as normal. The problem is with ChildC which can be called at any point during run time. When it is invoked, it is loaded as the others are. ChildB redraws its bottom to be roughly half of the client height and ChildC draws its top at ChildB.bottom and its ChildC.bottom equal to client_y - status_bar.height
(these aren't real variables, just trying to be clear.
ChildA.bottom is ALSO equal to client_y - status_bar.height, again this looks perfect.
Looking with a debugger, both ChildA and ChildC have the same bottom value (447 in most cases). The thing is, ChildC ignores this value and draws well beyond the client area. I have to set it's bottom to be client_y - status_bar.height - 400 before I can even see the bottom of the window ???
I've compared window settings between all the children 100 times or more and am convinced they are all identicle (save for the controls they have).
Has anybody ever seen behaviour like this before? Or have any idea what it is I may be doing wrong?
I typically use MoveWindow(...) during the WM_SIZE call, but have experimented with SetWindowPosition(...) just to see if it would help.
I am coding with VC++ 7.1
thanks for any help/advice that you can offer.
Dave
|
|
|
|
|
It seems to me that ChildC is not being created as a child of the parent window that is controlling ChildA and ChildB. It might instead be a child of the desktop, and this could explain the '-400' you offset to modify its position. Double check the parenting for ChildC and see if that solves your problem.
|
|
|
|
|
Hi Blake and thanks for replying.
I double checked the parentage as you suggested. All three children are created in the WinProc(...) callback and all three use the same variable for parent (arg 1: HWND hWnd). Because I wrapped the creation process in a seperate function for each, I took the time to trace the process with the debugger so that I could actually eyeball the value of the handle, and it is indeed the same parent.
Another "strangeness I noticed last night while poking around at this issue: if I draw ChildA down to client_y, the two positions meet and form a nice 2px wide grey line (looks docked in other words). If I manage to get ChildC drawn to the same position, that 2px line forms, but it turns black instead of staying grey. I just don't understand the differnt behavior.
just to make sure the dialogs are being created the same, I opened up the *.rc and eyeballed the script:
ChildA:
DLG_TREE DIALOGEX 0, 0, 173, 154
STYLE DS_SETFONT | DS_FIXEDSYS | DS_CONTROL | WS_CHILD | WS_VISIBLE |
WS_CLIPSIBLINGS | WS_THICKFRAME
EXSTYLE WS_EX_TRANSPARENT | WS_EX_STATICEDGE
ChildB:
DLG_RECIPELIST DIALOGEX 0, 0, 301, 159
STYLE DS_SETFONT | DS_FIXEDSYS | DS_CONTROL | WS_CHILD | WS_VISIBLE |
WS_CLIPSIBLINGS | WS_THICKFRAME
EXSTYLE WS_EX_TRANSPARENT | WS_EX_STATICEDGE
ChildC:
DLG_RECVIEW DIALOGEX 0, 0, 331, 151
STYLE DS_SETFONT | DS_FIXEDSYS | DS_CONTROL | WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS |
WS_THICKFRAME
EXSTYLE WS_EX_TRANSPARENT | WS_EX_STATICEDGE
I'm completely confused. The only other thing I can think of is to try creating the window at the time that the other two are created ??? I fail to see how that would help though... but I've given up on logic at this point and am happily grasping at straws 
thanks for the input!
Dave
|
|
|
|
|
One more straw to grasp at.
I am not EXACTLY sure what the consequences of 'clipping a sibling' are. But suppose they accidentally overlap, even by one pixel. So, try perhaps removing the WS_CLIPSIBLINGS, just for grins, and see if that solves the problem. Maybe 'C' overlaps just a tad, and since it is clipped, it does not get draw messages, or some other bizarre side effect you did not anticipate. Just an idea, anyway.
|
|
|
|
|
Blake...
That was it I turned off the clipping for all three and it looks perfect and behaves as expected now.
Thanks so much for the help, after a week of that nonsense I'm tickled pink to see things line up
Thanks again
Dave
|
|
|
|
|
I can't figure out why the main menu component is not available on my dialog editor. It is grayed out along with Picture and Text components.
Thanks
-md
|
|
|
|
|
Hi,
I'm trying to gather network statistics for various LANs connected to a computer (if the adapter is active, number of packets, packets per second, number of collisions, etc). I've searched quite a lot for a way to do this but haven't had much luck.
Any help? 
Thanks!
Cheers,
Bail Organa
|
|
|
|
|
Does this article help?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi,
Thanks for your reply!
Does it help? No, not really! That article deals with TCP statistics (and more). I need actual ethernet statistics (ie, one layer down, if I'm not mistaken) such as the number of packet collisions.
Cheers,
Bail Organa
|
|
|
|
|
TCP resides at the Transport layer. Does what you are after reside at the Network, Data Link, or Physical (doubtful) layer?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hello,
My app draws its own array of lines with a CButton array inside the OnDraw() method. However, when resizing the window, the lines look good, except that the background of the previous CButton window positions is white (erased). Upon overloading the OnEraseBackground() method in the CButton class, I see that it’s called AFTER the lines are drawn in OnDraw(). How do I get the background erase method to execute before the lines are drawn? Or, how do I get the CButtons to be updated COMPLETELY before the lines are drawn (the code draws the lines after calling the CButton.MoveWindow() methods ).
thanks,
JennyP
|
|
|
|
|
Very Strange, the OnEraseBkgnd should always be called before OnDraw. Anyway, one possible solution would be to call ExcludeClipRect or ExcludeUpdateRgn in the OnDraw function so that any future drawing will not draw over what has already drawn.
Note: The above may lead to unusual drawing, if OnDraw is realy called before OnEraseBkgnd.
What I recommend is to see if you can reproduce the problem in a simple test program (the smaller the better). This will allow one of us to see how OnEraseBkgnd is being called first (or you to see how that is happening).
I have found that if you override the OnEraseBkgnd to return TRUE and override the OnDraw function, so that it calls ExcludeClipRect or ExcludeUpdateRgn to validate anything you have drawn, is a great way to elimenate any flicker.
If you find a solution please post it (or write and article [prefered]).
If what you describe is actualy happening, I feel for you. It's one of those things that makes us want to pound are head against the wall (very depressing).
Good Luck, and keep progamming!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Thanks for the reply! View class contains an array of CButtons, so the CButton’s Erase is being called after the View’s OnDraw() method which moves the CButtons (MoveWindow()). Please see my other reply to this thread for a more complete description (I don’t want to double-post).
Thanks!
JennyP
|
|
|
|
|
what's mean "with a CButton array",which class does th OnDraw() method belong to?
your friend:bobi
|
|
|
|
|
Thanks for the reply. The View class contains an array of CButtons that it creates upon init-dialog. Then, in the View’s OnDraw() method, these buttons are repositioned (MoveWindow()) based on the user’s resizing the overall view. After calling MoveWindow(), I draw a bunch of lines (dc->LineTo()).
When the app is running and the user resizes the view, the lines all have blank squares imprinted over them where the CButton(s) used to be (i.e., before they were moved with MoveWindow()).
When I insert debug TRACE()s, I see that the CButton’s OnEraseBackground method is temporally executed AFTER the View’s OnDraw() is completed. I suspect that the MoveWindow() simply puts a message in the queue for the CButtons to erase themselves. However, I want this operation to complete immediately before the lines are drawn.
Any suggestions?
Thanks!
JennyP
|
|
|
|
|
just to be sure I do this the right way ...
I have a vector of something and I want to sort it according to a criteria; so I define a class as the criteria, and I want to pass some context to it ( some additional global thingies )
typedef std::vector < something > vectorOfSomething_t;
vectorOfSomething_t myVector;
...
vectorOfSomething_t::iterator start = myVector.start();
vectorOfSomething_t::iterator end = myVector.end();
std::sort( start, end, myCriteriaFunctor );
...
class myCriteriaFunctor
{
public:
myCriteriaFunctor ( bool b, int i ): m_vp(vp), m_bSortOrder( b ), m_iSomeContext(i) {};
private:
bool m_bSortOrder;
int m_iSomeContext;
public:
bool operator() ( something& something1 , something& something2 ) const
{
bool bSmaller;
...
return bSmaller;
};
the question, is it kosher to pass data like that to a sort functor ?
It's working right now, and I just want to be sure ...
Thanks.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
I do not see any problem with your code.
Looks good.
My site - Body Jewelry
|
|
|
|
|
That's perfectly fine, the usual way of doing it is to create a temp object in the sort() call and pass the appropriate data to its ctor:
std::sort ( start, end, <font color=red>myCriteriaFunctor(true, 42)</font> ); If you need the object lifetime to be longer than just that one line, you can create it on the stack like any other C++ object. (A "functor" is a C++ object, after all, it just also has an overloaded operator() for STL to call.)
--Mike--
LINKS~! Ericahist updated! | 1ClickPicGrabber | CP SearchBar v2.0.2 | C++ Forum FAQ
Strange things are afoot at the U+004B U+20DD
|
|
|
|
|
Hi,
I'm a bit confused with the copy constructor business. A book I found says that given a variable 'a' of type MyClass, if you have:
<br />
a = SomeFunction();
then the copy constructor of MyClass would be invoked. None of the examples I've seen on the net ever try to delete memory inside a copy constructor. They only allocate new memory and copy the stuff. However in this case 'a', would already exist with some memory being used and would result in a memory leak? If the book is wrong and the operator=() is called then that makes more sense. Or possibly most of the examples I've seen are wrong and you should always call delete on your memory in the copy constructor.
Thanks for cleaning this up. If you know of a good resource on the net on this topic let me know.
|
|
|
|
|
Hi friend,
I don't know what kind of book you read, but i think that you might missunderdstood the issue.
In the example you wrote:
a = SomeFunction(); //returns MyClass object
You are right, the operator= is called, but have you read the implementation of operator=...?
if you are using a default version of operator=, then you will get a call of the copy construcor because its implemntation goes like this:
<br />
M operator=(const M &m)<br />
{<br />
return m;
}
because a copy of object m is returned BY VALUE, not the actual object will be returned, but a copy of object m. No memory leak will occur because this temporary object is created on the stack!
Furthermore, if you create an object with the operator=, the copy constructor will be called instaed of operator=
MyClass new=old; //copy constructor is called.
A good resource is the book Thinking in C++ version 2, it is available on many sites for FREE. use a search engine to find it.
Good luck,
Mohammad Gdeisat
|
|
|
|
|
Well, the default assignment operator generated by the compiler will *NOT* result in a copy constructor call. It does a bitwise copy and that's the source of the dangling pointer problem.
And if you define your own operator =, you're supposed to return a *reference*, otherwise chaining the operator like a = b = c won't work. A typical operator = overload will look like this
M & operator = (const M& val)
{
// do the job
return *this;
}
Regards
Senthil
My Blog
|
|
|
|
|
Hi,
yes you are right about the implementation.
But you can write a program and a class, with Copy contructor and operator= implemented , and write cout statements to trace program flow.
Its really a tricky behaviour,
Regards,
Mohammad
|
|
|
|
|
Well, you're right. And so is the book's author, if SomeFunction returns a value and not a reference.. Both the copy constructor and operator = will get called. How? SomeFunction returns a value and the compiler invokes the copy constructor to create a temporary object. It then calls operator = on a, passing the temporary object.
And yeah, you are right, inside the overloaded assignment operator, you need to check if you have a valid pointer and if you do, delete it before copying the contents. This is not needed in a copy constructor because it can be invoked only once, when the object is created.
You need to watch out for something called return value optimization though. If you write code like this,
<br />
Class a = SomeFunction();<br />
then the compiler is free to optimize away the call to the copy constructor and instead construct a directly in place. So the above code will result in only copy constructor call, instead of the two you expect (one for the returned temporary object, one for a).
Regards
Senthil
My Blog
|
|
|
|
|
If 'a' already exists and you wish to replace it with data from anouther object then you must free any memory that your object allocated before copying the data. But to be safe, you must first determine it you can make a copy of the data. Which means if an allocation is needed, then allocate the required memory. If the allocation fails then throw an exception (or return an error condition). If the allocation is successfull, then free the previous memory pointers and set them equal to the newly allocated memory pointers. The idea here is to leave the object ('a') in the same state that it was in before the copy was attempted.
There is a differnce between the following:
MyClass a = b; // 1st - object being initialised
a = c; // 2nd object data being replaced
In the 1st case the code calls the copy constructor MyClass::MyClass(const MyClass& argumentMyClass).
In the 2nd case it calls the operater MyClass::operater=(const MyClass argumentMyClass).
The 1st case is easy, but it must(/should) throw an exception if a memory allocation fails (because constuctors do not return a failed/success value).
The 2nd case is a little different, because 'a' alrady exist. We have to free any memory associated with it, before reassigning the data pointers.
Now here is the flaw in the sytstem, if you don't delete your current objects data pointers before allocating space for the new data then there may not be enough memory to make a copy (highly unlikely - but possible). If that is the case then you are running so low on memory that it does not matter (just throw an exception or return a major error value).
General Rule: Any time a function/routine fails, the state of the object/data should remain in the state that is was in before the failure.
 Sorry, I tend to get a little carried away. This is a fraction of what you may have to deal with, when it comes to copy constructors.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
