Hi everyone… i deaigned a form for a small business… i have two textboxes and a grid… the first is texbox.valid for getting product code… that will ahow up in the grid… my problem is i cannot go to the second box for quantity… because of the “valid” in the textbox1. Is valid gud for data entry in the product code? Or is there another way ao that i could also click the second textbox for quantity? Thanks and godbless…
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to design Point of sale system? 1
- Thread starter Mandy_crw
- Start date
-
1
- #2
Chris Miller
Programmer
First of all, there's so much more to a POS system than entering a product code (usually a barcode scanned) and then a qty to have an item on the receipt with product name, qantity, price, etc. It's common to need to provide a cryptographically processed temperproof ledger of receipts, just for example.
Why would you want to first enter the quantity, in a POS system the normal situation is products scanned, so the first thing known is the product, and then there can be a quantity, discount, different taxes and whatever else matters.
So I think the valid is used good for this case. What would you do with a quantity of a product, for which you can't provide a good product (bar)code? You'd have to have an alternative way of identifying or selecting the product. And it still is the first thing of interest.
Chriss
Why would you want to first enter the quantity, in a POS system the normal situation is products scanned, so the first thing known is the product, and then there can be a quantity, discount, different taxes and whatever else matters.
So I think the valid is used good for this case. What would you do with a quantity of a product, for which you can't provide a good product (bar)code? You'd have to have an alternative way of identifying or selecting the product. And it still is the first thing of interest.
Chriss
Mike Lewis
Programmer
In general, I would prefer LostFocus rather than Valid. As its name suggests, Valid is intended to validate the value of the control, with focus remaining in the control if the value fails the test. As I understand it, that's not what you are doing here. (Correct me if I am wrong about that.)
More specifically, it's not clear what you are trying to achieve with the grid. When you say the product code "will show up in the grid", do you mean that the grid will show all products with that code and the user will choose the correct? (That doesn't sound right. Why would multiple products have the same code?) And why exactly can't you then enter the quantity.
A simpler solution would be for the user to enter the product code, and for the program to immediately display the name or description of the product for the user to verify. Focus would then move straight to the quantity box. But it's difficult to be sure about that without understanding what you are trying to achieve.
One more point: If this is a point-of-sale system, as the title of your post indicates, it's much more likely that you would use a bar code scanner to input the product code.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
More specifically, it's not clear what you are trying to achieve with the grid. When you say the product code "will show up in the grid", do you mean that the grid will show all products with that code and the user will choose the correct? (That doesn't sound right. Why would multiple products have the same code?) And why exactly can't you then enter the quantity.
A simpler solution would be for the user to enter the product code, and for the program to immediately display the name or description of the product for the user to verify. Focus would then move straight to the quantity box. But it's difficult to be sure about that without understanding what you are trying to achieve.
One more point: If this is a point-of-sale system, as the title of your post indicates, it's much more likely that you would use a bar code scanner to input the product code.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Valid is correct, as a non valid product code won't help the system to determine a price. It's essential so I would use the valid. The product code textbox should only get focus, when it's time to enter a product code, though. That's surely the first step of serving a customer, but the system can't know how many items are purchased, so ou should only set focus to a control with code in valid when you're sure another product code is necessary.
The usual solution using a barcode scanner is programming a prefix the scanner sends before the barcode, the prefix will set focus to the product code textbox. That way you can almost be sure you get into the box and out again just shortly after the barcode is recognized. It only fails when the barcode can't be read, but most scanners then also won't send the prefix. Or if the barcode isn't in the data, that could lead to an invalid state sticking in the barcode box.
You can always allow an exitcode like all zeros or empty to be valid, resulting in the follow up logic NOT firing, as there is no product, price, so also no quantity or other things related to this receipt position. I'd not program the POS to ever just be in such a textbox for sake of doing anything else in the system between serving customers, like inserting a new product, defining discounts or whatever else is done with the system. The product code textbox could be made to only accept focus in the when, if it detects the hotkey that needs to be used to focus the textbox and so manually entering this "trap" you can only exit with a valid product code is made harder and you don't accidentally get trapped there. Besides an empty or 0 code letting you out again. It's overall feasible to do and gives control over the workflow, so I would still support the idea despite what Mike interprets.
I think you want to enforce a valid product code at some point in the process. It doesn't make sense to continue with an unknown product, unless you don't care about keeping stock and accept the cahier to simply enter the price for an unknown item and continue. But that could still be done with the idea of the exit code you allow as product code for "unknown product", maybe another code like 1 instead of empty or 0. And then you don't fall back to awaiting a valid product code but allow the cashier to enter a price for the unknown product and continue.
Chriss
The usual solution using a barcode scanner is programming a prefix the scanner sends before the barcode, the prefix will set focus to the product code textbox. That way you can almost be sure you get into the box and out again just shortly after the barcode is recognized. It only fails when the barcode can't be read, but most scanners then also won't send the prefix. Or if the barcode isn't in the data, that could lead to an invalid state sticking in the barcode box.
You can always allow an exitcode like all zeros or empty to be valid, resulting in the follow up logic NOT firing, as there is no product, price, so also no quantity or other things related to this receipt position. I'd not program the POS to ever just be in such a textbox for sake of doing anything else in the system between serving customers, like inserting a new product, defining discounts or whatever else is done with the system. The product code textbox could be made to only accept focus in the when, if it detects the hotkey that needs to be used to focus the textbox and so manually entering this "trap" you can only exit with a valid product code is made harder and you don't accidentally get trapped there. Besides an empty or 0 code letting you out again. It's overall feasible to do and gives control over the workflow, so I would still support the idea despite what Mike interprets.
I think you want to enforce a valid product code at some point in the process. It doesn't make sense to continue with an unknown product, unless you don't care about keeping stock and accept the cahier to simply enter the price for an unknown item and continue. But that could still be done with the idea of the exit code you allow as product code for "unknown product", maybe another code like 1 instead of empty or 0. And then you don't fall back to awaiting a valid product code but allow the cashier to enter a price for the unknown product and continue.
Chriss
- Thread starter
- #5
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
