|
Hi, thanks for your response !
I admit to a bias about using "Okay:" to me "Okay" is appropriate for confirming a direct question that is "binary" in nature. I like "Save" better: personal taste.
I can't imagine a case where preference "settings" are not already in memory in order to be used in the Application, "embodied" in some kind of data-structures: with that in mind: "revert" is easy.
I also prefer to see a "Save" button disabled as long as no changes have been made, and enabled when they have: similarly, I like the idea of a "Revert" button also disabled until changes have been made (although that could also be handled, as I noted in my first post, by Control-Z/Y keyboard functionality).
I do think use of separate 'Revert' and "Cancel" controls are sometimes appropriate. The idea of "revert" on a per setting basis, perhaps using color as a flag to indicate a changed value, as raised by Luc, I find very interesting.
You wrote: "There is no confirmation on exit. After all the user either explicitly wanted to change something so they are going to hit 'Ok' or they accidentally changed something and a confirmation is going to confuse them."
On this issue I respectfully disagree: if I have "waded into" a complex configuration UI, and made many changes: or changed something accidentally: I definitely want to know on exit if changes have been made ... most strongly when I am under the impression (in error) that I did not change any preferences.
thanks, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
BillWoodruff wrote: I also prefer to see a "Save" button disabled as long as no changes have been made, and enabled when they have: similarly, I like the idea of a "Revert" button also disabled until changes have been made
That is adding complications with no benefit.
Scenario
1. Monday I changed config value X. And save/ok.
2. Tuesday I changed config value Y. And save/ok
3. Wednesday I can't figure out why it isn't working the way I want but I guess 1/2 had something to do with it. So I want to revert to the original default settings.
To handle the above case then you must do a comparison with the original values every time you load. That of course complicates things.
But there are only two cases.
A. The user has in fact made a change in the past. So Revert is always on and will always be on.
B. The user has never made a change in the past.
In the first case it matters if the user hits Revert. In the second it doesn't matter at all.
So you are doing work that doesn't mean anything. So pointless. Revert should always be enabled and should just always copy the original values into the use location.
And it could be the case that a config value must always be changed, such as if a database is required. In that case revert would always be enabled for everyone.
BillWoodruff wrote: I do think use of separate 'Revert' and "Cancel" controls are sometimes appropriate. The idea of "revert" on a per setting basis, perhaps using color as a flag to indicate a changed value, as raised by Luc, I find very interesting.
Depends on you and your app of course but exactly what sort of config values are these?
For example if I have an inventory app and I set the database host name, I don't need to do it again.
If I have an editor and I want to change the font color then it is pretty obvious what it is, and I certainly don't need a reminder that I changed it.
BillWoodruff wrote: On this issue I respectfully disagree: if I have "waded into" a complex configuration UI, and made many changes: or changed something accidentally: I definitely want to know on exit if changes have been made ... most strongly when I am under the impression (in error) that I did not change any preferences.
You must be dealing with different sorts of users then.
If I am writing an editor then I expect that the users know that they are actually using an editor and that they expect certain functionality from the editor. If they go poking around in the config font colors for the editor and change it I don't expect it to be confusing to them when the the font color does change.
And if there are config values that users shouldn't be messing with in most cases then I am not going to make it easier for them to do so. So no UI in the first place.
But for comparison I looked at some apps.
TextPad
- Has a Ok button, always enabled, not sure of the point but I presume it does 'Apply'
- Has a Apply button. Only enabled if I change something.
- Has a Cancel. Always enabled.
- No revert at all.
VS 2010
- Has Ok and Cancel. Both enabled. No other buttons.
Cisco VPN
- Has Ok and Cancel. Both enabled. No other buttons.
Firefox
- Has Ok and Cancel (and Help). All enabled.
WinAmp
- Has Close (only the one button.) Always enabled.
Given the above just having simple revert puts you way ahead of the curve. Of course that could be problematic I suppose. I don't want the inventory app to ever return to the factory database host, since that probably is always wrong.
|
|
|
|
|
Hi,
I have a "philosophy" of interface design, which I am continually modifying: it's been an interest going back to SmallTalk on the Xerox Alto.
I am highly critical of many design aspects of Windows up to and including version 7.
Equally critical of the "bright chiclet auto-expanding" graphic chotchkas of the current Mac UI desktop (but, that's a "religion," after all).
In your response above I find a dis-jointed potpourri of the ideas of "Save," "Apply," "revert (undo)," "multiple revert (undo)," and "restore application setting defaults for the whole banana." Not to mention the ideas of saving complete, or partial, "snapshots" of part, or the entire, state, of an application.
Each of those implementation details, imho, will be more or less appropriate depending on application design, purpose, security concerns, etc., and level of sophistication of end-users. The "security fence" I'd want a System Admin to be in, where changing a setting that might affect a hundred computers on a network needs a rigorous confirmation process, is irrelevant to TextPad or Angry Birds 
In some cases you want highly specific undo/redo facilities with a perhaps user-configurable history mechanism (as PhotoShop does for undoing graphic operations per document, for example, where the end user can specify the number of history states to be maintained) for certain types of UI actions, but have no need for such mechanisms with other properties of the application.
And the kind of configuration/settings I am speaking about are not trivial, self-evident, modifications like the background color of selected text in an editor application, like UltraEdit.
The trivial case in which "Okay" is "okay:" is one in which there is a simple binary choice affecting one user setting or preference, or where the visual cues in the settings area show you exactly what you are going to get when you do click "Okay: like in UltraEdit's compex configuration panel for setting the foreground and background colors of no less than ten text parameters. However UltraEdit also has a 'Save' button on that modal dialog that will auto-increment, and you can then re-open any previously saved configuration, which is quite handy ... no need to type an "original name" every time for each new configuration saved.
As I've carefully explained in my original post, and in my comments to other posts on this thread, I think there is a continuum of confirmation-requirement by the end-user that varies with the context in which the application is used.
The program examples you mention, including Visual Studio, have some absolutely grotesquely stupid design decisions. UltraEdit, while my tool of choice, for all text editing, in use every day, scatters its complex configuration UI's across multiple top-level menu items. To me "WinAmp" is the design equivalent of a Pachinko machine
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
Hi there,
Anyone knows the best way to use barcode in an inventory and POS system? I mean should I simply just read the barcode and use the Part number as an ID (Primary key) for the item, or is there a better way?
Thanks.
|
|
|
|
|
First step is to investigate "bar code". These days there are many variations.
You probably mean a UPC code which is a specific form and type of bar code.
I suspect that you probably don't want it as the primary key because it might need to be changed. You might want to also consider what happens in the following scenarios.
1. The cashier must manually enter the code but they enter it wrong. How does this impact inventory? How is a correction handled? (Think of fraud control in terms of this.) What happens to returns? What happens to returns if it was corrected before the return happened?
2. The cashier scans a item but the UPC code is not found in the database - now what?
|
|
|
|
|
Omar Rwemi wrote: I mean should I simply just read the barcode
Yes. Most scanners will input the code as if it were entered by the keyboard.
Omar Rwemi wrote: and use the Part number as an ID (Primary key) for the item, or is there a better way?
Yes. Add an identity-field (or a guid) as a primary key, and put an index on the part number
Bastard Programmer from Hell 
|
|
|
|
|
Each item in inventory should have a unique identifier, but don't count on each having a unique bar code. Manufacturers frequently change bar codes, and you'll often need to have several equally valid barcodes associated with a single item. Another thing to keep in mind is that sometimes a clerk will scan a barcode associated with a case lot, rather than the single item code. I had this happen when I was managing inventory at Ace Hardware. Fluorescent tubes came in a case of 30, and the case had a barcode different from the one printed on each individual tube. Somebody entered the case code into the system as an alternate to the one used for individual tubes, and some of our clerks sold cases at the single tube price. An honest customer pointed out the error, not an observant clerk (of which we apparently had none), but only after we came up short about 1500 tubes. 
Another thing to keep in mind is that a single item can come from multiple vendors and manufacturers; this happens a lot for generic items. For instance, we use a ball clevis rated at 30,000 pounds for stringing power lines. There are at least 6 manufacturers of this item, and except for cosmetic differences, they are all the same. We stock one item number, but each will have a different part number (for ordering purposes), and a different barcode.
This is actually a very complex kind of program to create, and there are a number of other caveats to beware of, especially if you plan to incorporate features like automatic ordering and receiving. Different vendors stock items with different order multiples, and the conversions between unit counts and order amounts can drive you crazy.
Will Rogers never met me.
|
|
|
|
|
Very good point, and you are correct. I've programmed POS systems for years. We used what we called an "alias" table for this. Ideally, you will store a system generated unique ID for your product in an items or products table. Then you will supply both a module and an import function to maintain your alias table for storing keyed values associated with your products.
ie:
CREATE TABLE ALIASES(
ID INTEGER IDENTITY(1,1) NOT NULL,
ALIAS NVARCHAR(50) NOT NULL,
XREF_ID INTEGER NOT NULL,
ALIAS_TYPE INTEGER NOT NULL,
DESCRIPTION NVARCHAR(100))
Note I used "XREF_ID" rather than a PRODUCT_ID. Keep in mind this table can be used for more than products. For instance, you may want to store aliases for customers, or vendors, or any other things people will look up stuff with. This is where the ALIAS_TYPE comes into play. These types can be maintained by a maintenance module associated with an ALIAS_TYPES table. This allows for dynamic growth of the system and modularization of your cross references.
I used an IDENTITY field for simplicity. But as Roger noted, it is probably better to use a GUID or some other form of unique value (i.e. STORE_NO + '-' + IDENTITY).
Getting back to the "Barcode" topic... you can store your Barcodes / UPC Codes / Model IDs / whatever in this ALIASES table and give them an appropriate type for searching on.
modified 6-Mar-12 0:36am.
|
|
|
|
|
Thanks everybody for the reply, lots of good info there, thanks
|
|
|
|
|
As a general rule, I avoid using business data as primary keys. The reason is, some time or the other they're susceptible to change. I understand that modern databases allow cascading updates, but I still feel that it is not an elegant idea and is not worth the pain and effort. I prefer using system-generated keys like GUIDs, IDENTITY columns (and SEQUENCE in Oracle). They're guaranteed to be unique and does not need to change at any point in time.
Don't forget to create an index on your barcode number, though.
|
|
|
|
|
Shameel wrote: As a general rule, I avoid using business data as primary keys
Ahhhh hah hah hah hah slap eh oh sorry...
A general rule - it is a cast iron, I will shoot you rule here, and I don't even have a gun. Absolutely NO flexibility in this rule is allowed - ever. The number of times I have gone, oh just this one, and had it come back and bite me is embarrassing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi All,
I am developing an antivirus scanner module for new security tool, in C++ for the windows operation system.
I have a need for database/list of viruses information so my tool be able to detect them.
Does any one know where i can buy/download a list like that with license to use in my tool.
I hope this is the right forum....
Thanks a lot,
Ram.
|
|
|
|
|
I've never seen an offer for such a list.
Furthermore, those lists are volatile; AntiVirus software manufacturers tend to update their data a couple of times a week. How will you organize that?
|
|
|
|
|
First of all, thanks for the reply.
I will have a team that investigate new threats over time.
But i need a list like that for old virus, that probably exist here and there....
Thanks,
Ram.
|
|
|
|
|
Luc Pattyn wrote: AntiVirus software manufacturers tend to update their data a couple of times a week daily.
FTFY
|
|
|
|
|
I am not sure about full list/database but if you visit the websites of the major anti-virus providers you should be able to find lots of useful information.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Thanks for the reply and the information.
|
|
|
|
|
Ram Shmider wrote:
I have a need for database/list of viruses information so my tool be able to detect them.
..scanning a file for a signature isn't the "hard" part that these people solve[^], it's getting those signatures.
Ram Shmider wrote: Does any one know where i can buy/download a list like that with license to use in my tool.
You're always welcome to download ClamWin[^], and build on it's database. You can even look at the sourcecode to see how it's done. If you use that database, your software might fall under the GPL license, dunno - you'd have to check with someone who knows about legal stuff.
A quick consultation with the Almighty Google revealed that Norton's database[^] might be "free" to. It might reveal more if you consult it after sacrificing some bacon.
Bastard Programmer from Hell 
|
|
|
|
|
Thanks a lot for the information, i will check it.
|
|
|
|
|
Hello, everyone, this is my first question in codeproject, please forgive me for my bad English.
Currently, I was working on designing a system which will store some data in local PC(ATM machine).
The customers(banks) hope we providing a security mechanism which can make sure any data recorded in PC was not changed by anyone.
I learned from internet and I fail to find a good way to handle it. Since we know if we have the right to visit the pc, we can changed the data, even though we can add MAC field for each records recorded.
I know that a third party CA organization would be involved to add proof to my application, but it is not allowed by my customer.
Any suggestion is welcome and highly appreciated.
|
|
|
|
|
in your database use datetimestamp field
|
|
|
|
|
Thanks for response, could you please detail it more specific.
|
|
|
|
|
Calculate a hash-key and store it in another table with a reference to your original table. If anyone modifies the data, it'll result in a different hash-key than the one that you stored.
Bastard Programmer from Hell
|
|
|
|
|
Hi Eddy, thanks a lot for that response, and I am glad to say you and I have a same understanding on that Issue.
From my previous thought, I think I can at least add a column in the data table, and record the hash key in this column, whereas you mean we can record the hash key in another table.
I think your idea is a little better than me, since if someone delete one row from data table the correlation will be broken for the foreign key doesn't match.
I want to know if tamper man change the data and meanwhile he/she change the hash key, how can we prove the data was not changed.
|
|
|
|
|
songbo07 wrote: I want to know if tamper man change the data and meanwhile he/she change the
hash key, how can we prove the data was not changed.
If the hacker can generate a new hash, you're toast. If the tamper-man has the seal of King Midas - he'll be King Midas.
It's the same as logging who's accesssing your Linux-machine - if a hacker gains root-access, they can change the logs as they like and the logs become useless. Hence the suggestion to store it somewhere else (with limited access).
songbo07 wrote: From my previous thought, I think I can at least add a column in the data table,
and record the hash key in this column, whereas you mean we can record the hash
key in another table.
I think your idea is a little better than me,
since if someone delete one row from data table the correlation will be broken
for the foreign key doesn't match.
Not only that; if a hacker sees a column with something that resembles a hash, he/she will focus on that column. If you got .NET code that's not obfuscated, then it might become very easy to break it.
Another layer of security could be added by adding auditing[^], but this requires a licensed version of Sql Server 2008 (not available for Sql Express, but you could leave a trace running there). Additionally, you can have the logs being written to an encrypted drive as suggested by Microsoft.
..and no, there is no fool-proof lock. The idea is to make it as hard as possible, just as you lock the doors around your house. Ask the bank, even their vault is vulnerable to attack in certain (yet hard to create) circumstances.
Bastard Programmer from Hell
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
