|
If you need help to finish it you should have STARTED.
What have you done so far?
What specific problems have you encountered?
Why didn't you pay attention in class?
Why do you expect busy developers to do your homework for you?
 ;P;P
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
I have the first bit written. it was stupid of me to write all of that. Just lost on the tax bit at the end.
Never, under any circumstances, take a sleeping pill and a laxative on the same night.
|
|
|
|
|
Hi,
Assuming I want to read the data that goes into a file w/o actually accessing the file on the disk. Could that be done if I know the name if the process which is writing the files and the file name ?
Basically, I want to look for some keywords in the file but I want to catch them while they are written w/o the need to access the file the regular way and search it.
Sounds strange , I know 
Shay
|
|
|
|
|
Seems like it should be possible, but it is obviously not a trivial task. At a minimum, a device driver would need to be created.
"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
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
