|
yeah i wanna learn not to copy thanks
|
|
|
|
|
hmaz4629 wrote: how to start it
I usually start projects using the File/New/Project menu command. Have you tried that yet? 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
In the past I have often had to do this - ie compress data/files. The best way is to use zlib as it is a defacto standard, open-source, unencumbered by any patents/licensing limitations and is supported in a large number of languages and environments. See http://zlib.net/[^].
You can also use my open source hex editor to play with all the options and features without writing any code. See HexEdit - Window Binary File Editor[^].
Andrew Phillips
http://www.hexedit.com
andrew @ hexedit.com
|
|
|
|
|
Please clear the below confusion;
1. Can you call "delete this;" inside a member function?
2. If Yes, What can you do after calling delete this?
|
|
|
|
|
It is allowed, but wreaks all kind of havoc depending on what the next statements are in your code.
An object instance didn't instantiate itself, so it should neither delete itself. There might still be refernces pointing to said ojbect instance which would become undefined if the object instance would delete itself.
Best Regards,
-MRB
|
|
|
|
|
u can do this but after this you cant access that mamber function or veriable which is being deleted....!~
|
|
|
|
|
hmaz4629 wrote: u can do this but after this you cant access that mamber functio
Technically that depends on the exact nature of the function and maybe the compiler.
I say maybe because I would suppose that most C++ compilers are going to generate static bindings for non-virtual methods simply because it produces faster code.
hmaz4629 wrote: or veriable which is being deleted..
That is certainly unsafe but the actual impact depends again on the compiler and what the variable is and how the application works.
|
|
|
|
|
You can do that, but with care!
Afterwards you can not access any instance variables. This implies you can call class methods (declared static) and also other instance methods as long as they don't access any instance variables (in which case they are not truly instance methods anyway.) You can still access class variables (declared static).
My recommendation is to not use it unless you really know what you're doing.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
