|
Have you gotten any ideas how to remove the program (Uninstall programmatically, better not using the Registry)? The EXE is locked while the program is running, so it fails to remove itself
There's a trick with a BATCH-file, but you have to make a little pause before invoking DEL within it to let the app exit first; that's quite a problem too
Any ideas?
|
|
|
|
|
Serge Baltic wrote:
but you have to make a little pause before invoking DEL within it to let the app exit first
Make a loop in the bath!
e.g:
1:
>delete here<
goto 1
I think it was something like that... 
------------------------------------
Rickard Andersson, Suza Computing
ICQ#: 50302279
I'm from the winter country SWEDEN!
------------------------------------
|
|
|
|
|
Why don't you create a kit with InstallShield and then you have install and uninstall
Best regards,
Alexandru Savescu
|
|
|
|
|
put a loop in the Batch file to delete specified file in a loop.
(Use ErrorLevel) and go back to the delete command.
This way it will delete the file once the file stops exec and
in the same manner you can delete the Batch file also.
|
|
|
|
|
Hi.
I think the best approach for the problem I am working on is to use the technique Prosise demostrates in his book using the CStdioFile class. It is a good alternative to serialization.
I need a way to edit the display the data in the file, which are most likely texts. I derived a view from CEditView. I looked to CEditView in MSDN and found that it is possible to get a reference of the CEdit object to modify data currently in the CEditView class. However, Visual C++ displays errors when I tried to gain access to CEdit.
Here is the code:
-----
CEdit myEdit = GetEditCtrl() // I saw this function in MSDN
int i = 0;
CString data;
while (myEdit->GetLine(i, data))
{
myCStringArray.SetAtGrow(i, i + 1);
}
-----
The code above is suppose to copy texts from whatever was stored in the CEdit class into an array of CString.
Visual C++ displayed this error:
C:\Projects\TextView.cpp(121) : error C2440: 'initializing' : cannot convert from 'class CEdit' to 'class CEdit'
No copy constructor available for class 'CEdit'
Am I doing something wrong as far as trying access the CEdit within the CEditView?
Kuphryn
|
|
|
|
|
Do you want to read MSDN again?
CEditView::GetEditCtrl
CEdit& GetEditCtrl( ) const;
Return Value
A reference to a CEdit object.
Remarks
Call GetEditCtrl to get a reference to the edit control used by the edit view. This control is of type CEdit, so you can manipulate the Windows edit control directly using the CEdit member functions.
! WARNING Using the CEdit object can change the state of the underlying Windows edit control. For example, you should not change the tab settings using the CEdit::SetTabStops function because CEditView caches these settings for use both in the edit control and in printing. Instead, use CEditView::SetTabStops.
Example
CMyEditView::OnInitialUpdate()
{
// get the edit control and set some initial properties for it
CEdit& theEdit = GetEditCtrl();
// adjust the left margin without changing the right margin
DWORD dwMargins = theEdit.GetMargins();
theEdit.SetMargins(20, HIWORD(dwMargins));
// only accept 10k of text
theEdit.SetLimitText(10 * 1024);
}
|
|
|
|
|
Okay. Thanks.
Key mistake: "&"
Kuphryn
|
|
|
|
|
Yes, but it's a very strong difference.
|
|
|
|
|
I created an MFC Extention DLL, and declare each class in the DLL with AFX_EXT_CLASS. It compiled fine, and the DLL was generated.
Now, I'm using the DLL's classes in a my application. In the application, I just coded something like :
<br />
CPacketAction* ppak;<br />
ppak = new CPacketAction();<br />
<br />
delete ppak;<br />
In the delete code, I got exception. The constructor and destructor didn't do anything, so it's just a problem of memory allocation. But, what's wrong ? It bothered me more than a week, but I couldn't solve it.
The error message in debug window is :
HEAP[TestServer.exe]: Heap block at 003B71E8 modified at 003B7270 past requested size of 80
Could anyone help ?
|
|
|
|
|
Forgot to tell, though the class's constructor didn't do anything, the base class did. It's derived from a base class called CPacketBase, which has a member variable called m_buffer of CBuffer type.
In the constructor of CBuffer, it does VirtualAlloc(...), and the destructor of it does VirtualFree(...). Will it be the consequnce of the memory access violation ??? If so, how can I solve it ?
|
|
|
|
|
I'm not quite sure if this applies to your problem, but you may want to check out
"Wrong Operator Delete Called for Exported Class ", ID: Q122675 at msdnlib
|
|
|
|
|
I do not know if this applies to your problem, but there are certain issues that you have to have in mind when working with DLL's and heaps.
If you allocate an object on the heap in your DLL, then DO NOT deallocate it from the calling application, because it may not be the same allocator used there!.
That is: the runtime libraries used are not the same, and so you may try to deallocate a piece of memory that is not referenced by the allocation structure, and this may lead to Unexpected Behaviour.
I may be talking BS here, because i never saw this problem in the real world, i just read it somewhere in an old WDJ issue, so i can't honestly tell you that what you are seeing is the result of such an error.
Jan
"It could have been worse, it could have been ME!"
|
|
|
|
|
As you can see from my code before, delete is the next line to new, so they should be new / delete in the same application, but just the declaration is in the DLL ... really so weired.
Hiya, Everybody ^^
|
|
|
|
|
Hi,
These two word always appear in my book, for example,
There is a class called CFn. And...
1> CFn fn; // this will create an object fn in stack
2> CFn* pFn=new CFn(); // this will create an object in heap
My problem is the advantages and disvantages of an object created in heap vs in stack. Plz explain them in detail.
Thank you in advance.
Best regard.
I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.
|
|
|
|
|
When you create an object on the stack, you are basically creating a variable in the current stack frame in which you are operating. Stack varaibles automatically go away when you exit the function call that they were defined in.
The heap is where dynamic memory is allocated from. When you declare an object on the heap, you have to allocate memory for it, usually with new or malloc, or in the case of the windows API GlobalAlloc. The pointer that you recieve from one of these allocations will not be destroyed until you explicitly destroy it. You can destroy heap memory that you have previously allocated with delete, free, or GlobalFree, each of these calls corresponding to the allocators that I mentioned earlier.
The advantages of the stack is that you do not have to manage the memory, just declare the variable and start using it. It will clean up after itself when the function exits. The disadvantage is that you have to know how much memory that you need at compile time, and the variables that you declare are not persistent outside of the function that they are described in.
The advantage of the heap is that you can decide how much memory that you need at runtime, and the variables will persist as long as you need them.
Checkout my Guide to Win32 Paint for Intermediates
|
|
|
|
|
The previous comments are correct, but one of the things most often forgotten about stack .vs. heap allocation is speed: stack allocation basically requires moving the stack pointer (register) to allocate a block of memory. Heap allocation includes overhead that can range from simple management of heap blocks and can go so far as to involve the operating system to request more free pages of memory.
Stack allocation of memory is much faster than heap allocation, and heap allocation is much slower than stack allocation. That is why you never treat CString or CComBSTR objects like they were free!
Also, the hidden information in the previous comment about stack memory cleaning itself up is that you should never pass the address of a stack-allocated variable to a function that may store that pointer. By the time that function gets around to using that pointer, the memory that the pointer points to will be invalid. Worse yet, it might not crash when it uses that pointer, it might just corrupt another function's local variables.
Lastly, heap access is normally serialized, which prevents two threads from messing with (allocating or deallocating memory) the heap at once, and that is good (but is the cause of a small part of the slwoing overhead). However, if you are doing any serious multithreaded development, you need to be careful of how you (mis)use dynamically allocated memory, and maybe even create seperate heaps for your threads, to reduce the effects of heap contention. Threads each get their own stack, so their stack allocations to not effect other threads.
Peace!
-=- James.
|
|
|
|
|
James R. Twine wrote:
heap access is normally serialized
I think you mean "synchronized". 
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Ravi Bhavnani wrote:
I think you mean "synchronized".
Quoted from MSDN docs: "To ensure thread safety, the heap has to serialize access to itself" and "The default behavior is to serialize access to the heap". True, a synchronization object is used for this.
The difference is that "Serialization" basically means "one thing after the other, and one at a time". "Synchronization" usually involves multiple threads at work, where two threads can actually try to manipulate something at the same time.
Although I agree as much as to say that the two terms are often used interchangeably...
Peace!
-=- James.
|
|
|
|
|
I'd like to add the formatting rebars seen in apps like word to a dialog I'm writing. Is this possible, or will I have to create my own?
skydiving....if at first you don't succeed, you're fecked!
|
|
|
|
|
Do you want to embed word control into a Dialog?
If:
you can send a app to you!
|
|
|
|
|
Do you want to embed word control into a Dialog?
If:
I can send a app to you!
|
|
|
|
|
Hi,
Plz look into this class, what will happen with static member variable?
class A
{
private:
char m_a1;
static double m_b1;
};
Tell me in detail, plz. Thank you in advance.
Best regard.
I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.
|
|
|
|
|
The variable m_b1 will exist once across all instances of this class. It could be set or accessed using A:m_b1, except that you've made it private.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
This might not be fully accurate, but I think the memory structure of an object created with the class will look something like this:
vtbl -> (functions)
m_b1 -> (one single instance of double)
m_a1
Each object share the vtbl and the reference to m_b1, and allocate memory for m_a1. There will only exist code for the functions and space for m_b1 at one place, no matter how many objects you create from the class. On the other hand each object will be able to access their own memory for m_a1.
/moliate
|
|
|
|
|
moliate wrote:
This might not be fully accurate [...]
Actually, it is pretty good, except for two things:
1: A class will not have a vtable in it's layout unless it has virtual methods (or inherits them from a base class).
2: The layout (placement) of the vtable is implementation dependent. It is correct for VC++ (currently), but might not be for other compilers, or in the future.
Peace!
-=- James.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
