i was thinking abt such a program which can block the inputs from keyboard n mouse until i enter the password...
is such a program possible or m just thinking haywire...
plz guide me...
and one more thing can i control the flow of data from a USB Drive. I mean no data should move automatically (viruses) from USB to PC and vice-versa. if user initiates a copy/move operation, the data can move... Can i???
Reminds me of the POST message "No keyboard detected. Press F1 to continue."
"Every program eventually becomes rococo, and then rubble." - Alan Perlis
The only valid measurement of code quality: WTFs/minute.
that is wat i was thinking.. but what if the application in pace of blocking the input simply does nothing on the inputs until a specific combination like ctrl+p is pressed to enter password... but the mouse still remains inactive.. no other key should be able to work.. like alt+tab which is used to change minimized windows should not be able to work... win button should be deactivated... and many more like it...
so tell me...
and the USB stuff... i want to to monitor the data which moves without user involvement... viruses just copy them self from usb to pc and fro.. this is very annoying...
Should be pretty easy with some sort of low level hook that blocks input.
If the password is x chars long, just keep the last x chars in memory but block them from going any further. If the last x chars match the password, allow any subsequent mouse or keyboard input to go through.
This[^] article should provide a good starting point. The faq also explains how to block keyboard input.
Whenever you do math between two number types you should expect your answer will be in precision of the lowest precision operand. You should either declare the 100 as a constant of the appropriate type or use Numeric type suffixes[^].
Just adding a .0 isn't good practice. Do you know for sure what type it becomes by adding a .0? It could be a decimal, or a float, or a double. Even if you know what type the compiler chooses by default, will other people who have to read or update your code? See my previous post in the thread for how to make sure the number you are dealing with is cast as exactly the type you need.
Sorry there is a mathematical mistake what I needed to know is when dividing an integer with a remainder I was getting
double variable(2425) / 100 would give you 24.0 , I was wondering why I wasn't getting 24.25
solution was because I was dividing an integer into another integer,
I corrected this simply by multiplying 100.00 instead of 100
dbRecipeTotal = (double)(((double)(RI.Quantity / dbRecipeTotalQuantity)) * ((double)(InvItem.Price / 100)));
this will make sure that you are always in the precision your looking for, indepentant of whether you use a lower precision numeral type.
ely_bob, your solution still doesn't work because (InvItem.Price / 100) will be 24, so ((double)(InvItem.Price / 100)) will be 24.0
It needs to be ((double)InvItem.Price / 100). I didn't cast the 100 to double because when one of the arguments to operator/ is a double, the other one is automatically cast (I think).
You are always going to store 24.25 in a floating point number exactly. 24.25 is a power of two. You should never see any of the results you listed (except 24.25) no matter what print formatting is specified.
[Stepping on my soapbox]
When dealing with floating point numbers, you should never assume that a number will be stored exactly. While some numbers can be stored exactly, most will not be.
From the cases I have encountered, too many people assume that a floating point number is good enough for exact numerical needs. But if the value 24.24999999999999 instead of 24.25 would be considered incorrect in your application, you should not be using floating point values.
Time and time again I have been called in to analyze why dollar values were coming in off by a penny or two (or more), and it has always* boiled down to the choice of using floating point representation to store exact values.
* Since 1992 I have encountered only 2 instances where the problem was an actual bug in the library.
Last Visit: 31-Dec-99 19:00 Last Update: 5-Dec-22 11:19