|
I think this is one of those things you can do but shouldn't.
|
|
|
|
|
You can and it might even work.
It however is always wrong.
|
|
|
|
|
jschell wrote: It however is always wrong.
Not always.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Odd.
Myself I would consider the design that lead to that requirement wrong.
|
|
|
|
|
This can be used to clean up when implementing COM objects in C++. E.g. when the reference count is zero in Release().
It puts some constraints on instance creation though. You will not get away with automatic objects for instance.
|
|
|
|
|
Like others have said, you cannot access instance member variables after delete this.
In addition, I would like to mention that if the object is created on the stack, it will crash.
So before you do this you have to ensure that the object is created on the heap.
You could probably do this on a singleton implementation.
|
|
|
|
|
You can, but you normally shouldn't. You'll destroy both the variables and the virtual function table (if you have one), so cannot access either. The only things you could still safely do is call static member functions or access static member variables.
That said...:
- What would happen if you allocated an array of objects of this type? -> crash!
- What would happen if you allocated the object on the stack, not on the heap? -> crash!
- What would happen if you allocated an object through malloc, a pool allocator, or any other non-standard memory allocator?
-> most likely crash
- What would happen if you allocated an object of a class derived from this one? -> might work, but could have undesired effects as you're calling the derived class' delete function which may do more than you intended
The only way to define such a class in a way that prevents any of the uses above is by protecting access to all the constructors and the destructor, and then provide create() and destroy() functions instead. Or use a friend helper class that does it for you (e. g. smart pointer or factory)
|
|
|
|
|
Hi All,
I'm writing a window explorer style application which has 2 tree controls embedded in a tab control on the left hand side and a report style list view on the right.
The list view has 15 columns that can be adjusted by the user. However, when I expand the column width all the way to the right,
the scrollbar does not adjust itself, therefore, the last column is not viewable anymore.
My current work around is making the view recalculate itself by inserting a hidden column and deleting it in the OnHdnEndtrack event.
It's definitely not a good solution, but I can't figure out how to get the scrollbar to work  .
I'm still a newbie in MFC, any help is greatly appreciated~~
|
|
|
|
|
TheHelenLee wrote: The list view has 15 columns that can be adjusted by the user. However, when I expand the column width all the way to the right,
the scrollbar does not adjust itself, therefore, the last column is not viewable anymore.
When you expand which column? All the way to the right of what?
We can't see your screen, or read your mind. Please be more specific.
In general, the listctrl handles scrolling very well, so what you're describing is very strange. What customizations have you made to the listctrl?
|
|
|
|
|
Hans Dietrich wrote: In general, the listctrl handles scrolling very well
The exception being the paint problems when using LVS_EX_GRIDLINES, with grid lines sporadically disappearing.
|
|
|
|
|
There is a well-known fix for this.
|
|
|
|
|
|
I haven't seen this problem at all on Win 7, so I hope Microsoft finally got around to fixing it.
The fix you found is basically what I have been doing on XP systems. If you use customdraw, there are a few other tricks you can use. For example, the function GetSubItemRect() is always incorrect for subitem 0; fixing this solves some problems.
I have also found that the cell rect is sometimes one pixel too tall. I'm not sure what the necessary conditions are for this to happen, but a fairly trivial fix is to reduce the drawing rect in the WM_CUSTOMDRAW handler.
|
|
|
|
|
Thanks for the info. Do you need to check the OS version before adjusting the drawing rectangles, or does your fix work on Win7 as is?
|
|
|
|
|
I don't check the OS version. I'm not sure what that would mean, since you can set the compatibility mode of an app to a different OS; haven't checked for this.
|
|
|
|
|
Hans,
It happens when I drag the resize bar on any columns. For example, if I expand the 12th column, it pushes the rest of the columns to the right of the view.
In window explorer, the horizontal scrollbar on the bottom would adjust dynamically so I can see the all the columns to the right of the 12th column.
In my list view, the scrollbar doesn't adjust at all, so column 13, 14, and 15 get pushed out of the list view.
I have these styles setup for the listctrl:
LVS_REPORT | LVS_SINGLESEL | LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES |LVS_EX_SUBITEMIMAGES
I hope I'm explaining a little bit more clear this time. Thank you very much for replying.
|
|
|
|
|
Without seeing your code, I would guess that you're not setting the columns correctly when you initialize the listctrl. In particular, look at the column widths you specify.
|
|
|
|
|
I probably did or didn't do something which caused the scrollbar to stop working in my listview.
I wrote the following workaround in OnHdnItemchanged and it sort of fixed the problem except that
if I push the last column all the way passes the right edge of my listview, the scrollbar thumb track
does not adjust or the view does not expand to include the last column.
int iTotalWidth=0;
for(int i=0; i < 16; i++)
{
int iWidth = GetListCtrl().GetColumnWidth(i);
iTotalWidth += iWidth;
}
GetListCtrl().SetScrollRange(SB_HORZ, 0, iTotalWidth,0);
Invalidate();
If anyone has any idea, please help!
Thanks!!
|
|
|
|
|
I have declared a variable
CADORecordset* m_Rpipe; in class
CPipeLineView
I call a method
bool DetectSeque(int pipeID) in class
CPipeLineView
In function
bool CPipeLineView::DetectSeque(int pipeID )
like follows
<br />
bool CPipeLineView::DetectSeque(int pipeID)<br />
{<br />
m_Rpipe=CPipeDAL::GetPipeByID(pipeID);
<br />
m_Rpipe->->MoveFirst();<br />
<br />
bool flag=false;<br />
<br />
<br />
<br />
<br />
while(!m_Rpipe->IsEOF()&&!m_Rpipe->IsBof())<br />
{<br />
<br />
if()
{<br />
.....<br />
}<br />
m_Rpipe->MoveNext();<br />
}<br />
return flag;<br />
}<br />
<br />,
as what is list above, errors accur while running at
m_Rpipe->MoveNext() .But when I put
m_Rpipe->MoveNext();
before
if sentence,it runs normally!
Please lend me a hand!
|
|
|
|
|
what errors do you get?
Additionally, I don't think you've pasted that code correctly - the second MoveNext() is out of the while loop and superfluous
How many rows are you expecting to fetch in this rowset?
|
|
|
|
|
I am sorry to make such a mistake.m_Rpipe->MoveNext() is in while loop
A dialog box pops up,which says "First-change exception in PipeLine.exe(KERNEL32.DLL):0xE06D7363:Mircosoft C++ Exception".
Thanks in advance.Do me a favor.
|
|
|
|
|
We need to know what exception you're getting ...
I would *guess* that the problem exists in your if(...) clause, and it seems to work when you put the MoveNext before it, because you're getting the second row of your rowset, which doesn't fulfill your if(...) test
Just guessing mind, there's not an awful lot to go on there 
|
|
|
|
|
I just want to scan all objects in recordset m_Rpipe while it fulfills certain condition.
There are no questions in if clause.
|
|
|
|
|
you need to run this under the debugger to find out what's going wrong
|
|
|
|
|
Ok,I'll debug carefully to find out the errors.Thank you again.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
