|
It has been a while since I did this, but I think you need to put the enum defines in the IDL.
Michael 
|
|
|
|
|
That makes good sense. Thank you.
I have looked for an example of the syntax, but have not found it.
|
|
|
|
|
Which is the prefered memory allocation method when the need for memory can be anywhere from 10 to 10mb...?
Would it be acceptable to use new over VirtualAlloc() under most circumstances....I read an article on VirtualAlloc and the author suggests using new whenever possible and you only need VirtualAlloc() if your gonna use major memory resources and stay running for long durations, like software running on NT. Is this generally acceptable practice...?
TIA
"An expert is someone who has made all the mistakes in thier field" - Niels Bohr
|
|
|
|
|
If you have a requirement that the pages you reserve remain in main memory and not swapped to virtual (possible disk memory)then VirtualAlloc gives you more control.
Are you writing some kind of service or kernel related task?
Do you reserve large chunks of memory but not always use it?
If none of the above is true then let the OS do what it does best and manage memory pages for you. Using New is much more acceptable as a general practice.
|
|
|
|
|
Just a generic text editor buffer, allocating 4096 byte pages. I would like to make the buffer grow to virtually unlimited size, but the hassle's I assume with VirtualAlloc are greater than the need for unlimited memory.
Heres the problem i foresee(spelling)
You can only lock 30 pages at any given call to VirtualLock, which creates the problem of not being able to lock once, move all, but instead i'd have to lock move 30 pages, unlock, lock again move another 30 and so on...am i right here...?
"An expert is someone who has made all the mistakes in thier field" - Niels Bohr
|
|
|
|
|
I have a program which creates an MCI window and plays a .avi movie.
At my school network, which runs win98, the program ran perfectly.
At home where I have win2k, it won't open. I've made sure the path is correct (the video is on cd as well so it's only something small like "H:\\movie.avi") and nothing was changed between the time I ran it at school and brought it home.
Are there any know problems with MCIWndCreate (or MCIWndPlay perhaps?) in win2k?
I'm quite curious as to why this doesn't work.
Thanks
|
|
|
|
|
I am trying to redraw the CHeaderCtrl contained in a CListCtrl and would like to handle WM_PAINT messages. Problem is when I do the control never stops painting.
Any help greatly appreciated
|
|
|
|
|
Post your OnPaint() code. Sounds like something you're doing in OnPaint() is causing another WM_PAINT message to be fired.
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
You didnt put an UpdateWindow in your paint handler, did you?
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
I'm getting an error when I try to get the contents of a CEdit control. I'm have a SDI MFC app that has a dialog bar. I put a CEdit control on it and I get an Assert error. I guess you can't do this in the Doc/View architecture because it works when I tested it in a Dialog App.
CEdit* pEdit =(CEdit*)GetDlgItem(IDC_EDIT1);
Any help would be appreciated becuase I don't normally use MFC
<marquee style="filter:blur(Add=1, Direction=90, Strength=4)">I ![Heart | [heart]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/love.gif) Microsoft and ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif)
|
|
|
|
|
This approach is fraught with error. You should store the edit control as a member variable and access it that way.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Just a suggestion, but why not use m_edit1.GetWindowText()?
|
|
|
|
|
From what context are you calling GetDlgItem?
The code you have should work, but only if GetDlgItem is called from the right context. For example, if you dialog bar is called m_dlgBar, then you should have, m_dlgBar .GetDlgItem (IDC_EDIT1). My best guess is that you are calling GetDlgItem from your main window class or a view window.
Then again, it has been a while since I used MFC and I could be wrong.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
In which of your classes have you put that code?
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Actually, I would guess that your problem is a result of timing. When are you calling GetDlgItem()? If you are calling it before the control has been created, you will get an assert.
Yes, there are people who argue that using GetDlgItem() is bad - don't listen to them! Both ways are valid. Form your own opinion! Check this article for a well-written explanation of one side...
J
|
|
|
|
|
That's the main error, I think. Because control in your dialog bar is not attached to existing CEdit object, GetDlgItem creates temporary CWnd instance and returns pointer to it. You use the temporary object.
This is how it should be done:
HWND hwnd;
dlgBar.GetDlgItem (IDC_EDIT1, &hwnd); // get the handle of control
CEdit wndEdit;
wndEdit.Attach (hwnd); // copy handle to the instance
// ... use wndEdit
wndEdit.Detach ();
Don't forget to Detach (), because as wndEdit goes out of
scope, its destructor destroys the window with the handle that it has last attached.
|
|
|
|
|
I still don't know the correct answer to this one.....
If you create a DLL and an EXE, both linked to use the DLL version of the RTL -- is it the case the the DLL and the EXE are using the exact same heap. Can you at this point, delete memory (in the EXE) which was allocated in the DLL?
If they are not, how do they do it? How would they manage to dynamically allocate a different heap to each DLL/EXE?
-p
|
|
|
|
|
Peter Weyzen wrote:
If you create a DLL and an EXE, both linked to use the DLL version of the RTL -- is it the case the the DLL and the EXE are using the exact same heap. Can you at this point, delete memory (in the EXE) which was allocated in the DLL?
Yes, and Yes.
I vote pro drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
My app keeps generating Access Violations after my program exits(More like after my code is finished and the system code is finishing up) and I can't find out why for the life of me... Any ideas as to what might cause this?
Also, are there any good Memory Monitors( like boundschecker) that are free?
Stephen Caldwell
Blackfission, CEO
|
|
|
|
|
Also, are there any good Memory Monitors( like boundschecker) that are free?
VC++'s C run-time library includes some rudimentary functions for out-of-bounds error checking and related stuff. Check MSDN article Debug Reporting Functions of the C Run-Time Library. Some samples are also included on the documentation.
Not very powerful, but they're good as a starting point as they're free and ready to use.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Have you managed to get the debugger to break on one of these Access Violations? 0xC0000005...
|
|
|
|
|
Go into debug mode and look at the call stack!
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Is there a way to tell how much stack space I need?
I have a multi threaded app that creates worker threads. There are very few variables in the main app. I am getting strange memory errors. Is it possible the default stack size for the threads (= stack size of main) is too small?
How can I find out how big it is?
How can I find out how big it needs to be?
I get no explicit errors, just lots of strange things.
Thanks for the help,
Bill
|
|
|
|
|
I'd say the default stack size is much more than necessary for the needs of normal apps. The only way a normal app can run out of stack size is because of some bug that causes an infinite chain of recursive calls to functions. But then again, you have no reason to suspect this is happening.
My suggestion is that you try to look for another reason to your strange errors. If you describe the problem with more detail we could try to help you more than this.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
My concern was that the actual stack requirements of a worker thread greatly exceeds that of the parent thread. The parent merely dispatches jobs to the workers. I thought maybe I didn't have enough stack space in the worker threads.
The specific problem (at the moment) is with using Crystal Reports. I have a wrapper class (CCrystalReports) that uses the CR API (not the com object). The wrapper has been used successfully in several single threaded apps.
I've tried this two different ways with different, but always disappointing  , results.
1. Make CCrystalReports a member of the Worker thread class. This mode of operation had no memory problems as far as I can tell. Crystal Reports, however, failed to open the report file in this configuration.
2. Make CCrystalReports a dynamic in a method called by the worker thread. (So it is automatically destroyed at the right time. This runs for awhile, then blows when trying to return from the method.
The actual blow up occurs in yet another program. The app I have been discussing supports a COM interface. Another program uses this interface to submit requests to the app, which then dispatches them to worker threads. The blowup comes in the Invoke call it returns the following error:
(8007000e) Not enough storage is available to complete this operation.
Any advice would be appreciated. This project has gone on too long!
Thanks for the help,
Bill
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
