|
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...
|
|
|
|
|
Thanks again for your patience.
I checked each of the TEXTMETRIC members and didn't see the answer.
tmHeight is the font size and tmOverhang is the extra width if I use Italic or Bold which I use none of them.
Still, If I choose "Ariel" with the size X and "Comic Sans MS" with the same size, the display font height are different. In addition, Using the same font, the letter 'a' and the letter 'b' have a different height. Therefore to know the real height of a specific font, the query method needs to the recieve the specific text in addition to the HDC. I am not sure there is such a method and I will be satisfied with known the difference between fonts
please advise
Thanks in advance, Udi Raz
|
|
|
|
|
I hope you don't mind me sneaking in here. I have the same problem with showing numbers in CEdit controls. How to find the TRUE pixel width of the text? I need to know how many digits can be shown in the control so that I can put in as many as possible, and round the number correctly.
It is easy enough to use DrawText() with the DT_CALCRECT flag, making sure that SetFont is done correctly, and for small font sizes the code works well. But as the fonts get bigger, DrawText's calculations just do not agree with those of CEdit.
I'm stumped too, and have temporarily had to restrict the font face and size, and apply magic numbers to get the stuff to work.
Shraddhan
|
|
|
|
|
Hi Shraddhan,
I get the filling that there is no way to get the real height, but as regarding the width, although I can't help you right now, I think in one of my attempts I got the real width using one of the following methods GetTextMetrics(), GetTextExtentPoint32(). It depands whether you are using a raster font or a open type/true type font.
I think that is works for me, but don't remember how. I still trying to find the real height...
Udi Raz
|
|
|
|
|
I couldn't find information on GetTextExtentPoint32.
GetTextMetrics returns a TEXTMETRIC structure that gives average and maximum character width, which are no good for my purposes.
Under GetTextExtent and GetOutputTextExtent, Microsoft notes:
Since some devices do not place characters in regular cell arrays (that is, they carry out kerning), the sum of the extents of the characters in a string may not be equal to the extent of the string.
So clearly ambiguous!
My notes on my problem with fitting strings into CEdit controls mention that the text is shown with white space on either side. In fact, with large font sizes. the output is chopped on the right if it gets anywhere near the edge of the edit box. But I have no idea what the whitespace allowance should be. It depends on the face as well as the size.
So is this a feature of CEdit controls?
As for finding the overall height, one last ditch method occurred to me: draw the text to a bitmap and measure the height of the drawn area by scanning the pixels. Don't ask me how, though.
Shraddhan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
