|
Thx,
I figured out is would be something that "sniffed" the hardware buffers.
Shay
|
|
|
|
|
I seem to be hitting an OS limitation on the number of threads I can create yet I'm only at 1G of 4G RAM usage according to task manager's performance tab.
I'm writting a small app for stress testing which spawns a bunch of job threads. Each job uses up two threads to do its dirty work. Is there a soft limit on the number of threads I can create? A registry setting perhaps?
Todd Smith
|
|
|
|
|
Hey Todd
The issue is that, since a process has only 2 GB of memory, and since each thread attempts to create a 1 MB stack by default, you are limited to about 2000 threads (maximum) per process.
Use the /STACK linker option to reduce the default thread stack size, and you'll be able to create a bigger number of threads.
Regards,
Nish
-- modified at 14:45 Monday 16th January, 2006
|
|
|
|
|
Nishant Sivakumar wrote: The issue is that, since a process has only 2 GB of memory, and since each thread attempts to create a 1 MB stack by default, you are limited to about 2000 threads (maximum) per process.
Use the /STACK linker option to reduce the default thread stack size, and you'll be able to create a bigger number of threads.
Ah that's it. Decreasing the stack sized helped. I guess I'll have to run multiple processes to get more threads.
thx
Todd Smith
|
|
|
|
|
Todd Smith wrote: Ah that's it. Decreasing the stack sized helped. I guess I'll have to run multiple processes to get more threads.
Yes, and if you are on an OS that supports the /3GB boot.ini option, use that as well.
Regards,
Nish
|
|
|
|
|
If you're running out of memory because of too many threads, you've probably got too many threads. You could consider using a thread pool - Look up the QueueUserWorkItem Win32 API.
Steve
|
|
|
|
|
Stephen Hewitt wrote: If you're running out of memory because of too many threads, you've probably got too many threads. You could consider using a thread pool - Look up the QueueUserWorkItem Win32 API.
His intention is to do a stress test on some app (probably teir company product). Almost attempting to DOS attack their app 
I guess it'd be simpler for him to run more processes, each spawning as many threads as possible.
Regards,
Nish
|
|
|
|
|
I didn't catch on to the fact that he was trying to do a stress test first time around (I should read the question more carefully before answering) - I guess he succeeded then!
Steve
|
|
|
|
|
Hi!
I have this software package I am maintaining and I have run into a small glitch because of the way CRecordView handles moves.
Imagine an entry window where you enter and update people. The key is an integer. If you enter a number in the key field the corresponding person is displayed. Now assume that you have a person on-screen and then change the number, but instead of leaving the field (which would trigger a lookup) you hit "PreviousRecord". This triggers an OnMove and that will do a save before the move and presto! You have changed the number of that person which was probably not what you intended.
The workaround which I have dreamed up on sleepless nights is to add a boolean to the class that all fields inherit from and check that in DoDataExchange, ie the field is normally FALSE, but TRUE for key fields.
In the DDX function I check if(pField->m_bKeyField && pDX->m_bSaveAndValidate) and only allow the DDX if m_bAddMode is true. For non-key fields I just do the DDX.
This will prevent updating the key field unless we are adding a new record.
How does this sound? Totally bad? Is there a better way?
|
|
|
|
|
How about just overriding CRecordView::OnMove() (it's virtual) and do everything that the base method does except for updating.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Yes, but the problem is that I do not want to block updates completely. Say that someone is moving through the records on-screen and updating them. In that case they will lose the update if they change a field and move to the next. It is just the key/id field that I want to protect on existing records. Am I making sense? 
|
|
|
|
|
Is it imperitive that this "key field" be manually assigned/updated? If not, just change the field in the database to be auto-increment. Remove that one field from the recordset class. When a new record is added, it will get the next available number. When the navigational buttons are clicked, no update to the auto-increment will take place.
Another option would be to add a "Go To" button next to the edit box containing the key field. That way, this button would not be tied to the other navigational buttons.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
"Is it imperitive that this "key field" be manually assigned/updated? "
Yes, unfortunately. The user must be able to specify new items. An analogy would be a POS system where the unique ID is the EAN-code.
"Another option would be to add a "Go To" button next to the edit box containing the key field. That way, this button would not be tied to the other navigational buttons."
Not sure that I follow you there?
|
|
|
|
|
Anders Gustafsson wrote: Not sure that I follow you there?
I meant to say there should be two additional buttons. One labeled "Go To" and the other labeled "Add." Now if you type in an item number and click the "Add" button, it will clear the form and add a new record with that item number. If you type in an item number and click the "Go To" button, it will populate the form with that item's information. If you click one of the navigational buttons, appropriate item will be displayed.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
OK. Problem is that I cannot rely on buttons alone. The app must be navigable by keyboard alone. Skilled operators get very nervous when they have to take their hands off the keyboard. At the same time the system should be friendly to novices 
One very drastic solution would be to disable the nav-buttons entirely, but that would make me rather unpopular with existing users.
Any thoughts about my idea to "mark" fields and prevent the DDX unless we are in add mode?
|
|
|
|
|
Anders Gustafsson wrote: Any thoughts about my idea to "mark" fields and prevent the DDX unless we are in add mode?
Sounds good.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
OK. Thanks. I will try that approach and have some users betatest it.
|
|
|
|
|
Remember the previous value in the key field and restore it in the PreviousRecord handler before doing the OnMove.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
"PreviousRecord handler"
Now you lost me? Where is that? Ie member of what class?
|
|
|
|
|
I mean whichever function gets called when the user presses "PreviousRecord"
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
OK. That means OnMove. But that would mean a rather complicated copy of OnMove in every data input view and there are at least ten of them for various tables.
If I prevent the DDX in the class (derived from RecordView where they all inherit, then I need just one line per data input view, to set one or more fields as "protected" unless we are adding a new record.
|
|
|
|
|
Hi All,
I want to draw text inside a bounding rect.Therefore I want to change the font size to fit the rect. I am trying to find a way to calculate the text width and height, knowing it's font.
Why do different fonts with the same size have different height?
Thanks, Udi Raz
|
|
|
|
|
See DrawText() with the DT_CALCRECT flag, GetTextMetrics(), GetCharABCWidths(), GetCharWidthFloat() and GetCharWidth32
onwards and upwards...
|
|
|
|
|
Thanks but already tried it all and everything else I found in the msdn regarding fonts.
The answer for the height in all methods is the font height. The problem is that fonts don't use the whole width to draw their characters. As a result, if I create a rectangle with the size x, a certain font with the size of x will be drawn perfectly well inside my rectangle but a second font (for Hindi fonts) will be drawn very small. What I need (and start to think there is no such a method) is a method that gives me the true height of the character.
Any Ideas?
|
|
|
|
|
Use GetTextMetrics(). Read the info on MSDN on font layout. You can then calculate the actual line height via the members in the TEXTMETRIC struct that is filled out from the call to GetTextMetrics(). Specifically, the tmHeight and tmOverhang members.
onwards and upwards...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
