This makes good sense. Up and Down Arrows (Not errors Peter ;-) ) are not really intuitive for moving left and right (or Next/Previous Controls). Also, it really is necessary to have navigation keys for moving up and down to the same Control in different records.
I agree. Disabling the control and hiding it (Setting .Visible to False) are not the same thing.
The latter is certainly something I believe would be a good addition.
It seems to me that splitting off Access into a separate subsidiary company would be a move towards separation rather than the increased integration that we all want for the product.
Please, just NO!
I still believe this one is a winner.
It may not be at the top of everybody's wish-list, but on the other hand is (probably) quite cheap to produce and would leave a more logical system to work within.
I take your point Mark, I really do, but if this is to be analysed seriously then I don't believe that can be done by avoiding questions.
The reason I asked the question (Is a password stored in a shortcut a less secure situation than a database with no password at all?) is that I see a number of scenarios where this parameter could be used to enable the use of password-protected databases more conveniently. If the worst that can be said against it is that it will surely be misused then I'd argue that is nobody's responsibility than the developer setting it up that way.
I'd certainly not recommend anyone leave their doorkeys under their mat in this day and age, but I'd hate to be unable to leave them with trusted neighbours because someone decided that the risk of people using their doormats outweighed the benefits of keys full-stop (or period for those across the pond). That seems a bit too nanny-ish from my perspective.
I have a real-world scenario where I upgrade my front end automatically by creating a CMD file on the fly and executing it. The file deletes itself when completed. Within that file is a call to run the specific (updated) front end file with Access and other parameters. A database password parameter would be useful to obviate the requirement to enter the password again for the operator. All operators at the company have to know the front end password anyway. Even to have a shortcut on the secured desktop of an operator is hardly a risk in this situation. Only that operator knows their own network password to get access to it.
Let us not forget that all scenarios are not equal. There are many where the level of danger, even for having it in a shortcut, is really not serious at all.
I am not arguing that there are no ways to use automation to get at a database. Clearly there are. However, I don't believe that has any bearing on this discussion. This is about the ability to open a database, with a password, using the Access command. Although automation can be used instead in many situations, it would essentially require a starter application be developed to cover all your password-protected databases. Not a message I'd want to be putting out on the forums.
You may want to explain how a plain text password stored in a shortcut is less secure than not being able to use a password at all - as pointed out in my previous comment. Unless anyone can explain (Logically - rather than simply expressing an opinion without foundation.) to the contrary, it seems clear that this suggestion, while not a perfect solution by any means, is better (or no worse at least) than the alternative (not having it) for each and every scenario that one could think of. After all, there is no reason for anyone to use it if they ever felt it wasn't a safe thing to use ;-)
On the other hand, it can be a great feature for those that know what they're doing and can lever the best out of it.
Re-reading Luke's original post I can see why someone could misunderstand the suggestiopn here.
The introductory paragraph was simply that. To help people to understand how the parameters, generally, are invoked.
That was not intended to indicate that would be where this requested parameter would be used. At least not in my reading of it. Luke can correct me if I'm mistaken.
I suppose, if it came down to it, a password-protected database opened through a shortcut is still more secure than one that isn't password-protected. Still, if decent security is required we still need this parameter. We simply have to understand how best to use it.
I have to disagree with that assumption.
No-one is suggesting that such a parameter be used from a shortcut. There are many many features that CAN be misused. That's a far cry from their being dangerous.
Actually, the way things stand is much more dangerous if you but think it through.
Without a password parameter developers are forced to ensure the database has none!
WITH a password parameter a developer who knows what they're doing can use it perfectly safely.
Far from compromising security, this gives the option of enhancing it.
I know we users always think everything's far more straightforward than they prove to be, I do believe this one should be easier to implement than most requests. I can be mistaken of course, but I think this one's a winner.
NB. My votes are all still tied up with many other items that are still under review, but this one will be the first to get any that become free.
Touch screen scrolling seems like a great idea to me. Not sure why you'd want to limit the idea to any particular area within the application mind.
PS. It's a shame that extra chatter doesn't encourage more developers to consider this idea for more votes. I think it's a good one.
If the code is written after the decision to add this, which surely it must be, then one could say that any such code should handle the possible scenarios adequately. I would expect to see an error thrown if a reference to non-existing property were attempted at runtime. This would be very similar to what happens now when cycling through controls on a form and trying to reference a property that didn't exist for that type of control (The .Value of a Label control for instance). Like you, I'd prefer an interface that could be inquired of rather than simply to rely on error handling, but either way you get what you need.
I don't see how this could affect any existing projects, but I hope I haven't missed something (Always possible).
I'm thinking, open to correction of course, that this would be straightforward to implement without upsetting any existing applecart. It's not like anything needs to be removed or changed from the original. Except in as much as is required to add the new features. Existing code/projects would be safe.
If what you say is what it takes then fine, but I don't imagine it should be necessary.
Obviously, this is a non-involved person speaking. We (MVPs) don't have that much of a view into what's going on at MSFT. This is simply my personal understanding at work here.
I believe this should be relatively easy to update (How many times have posters said that and been completely wrong?) and, though might not be used by a great number of developers, is a fundamentally necessary development towards making the interface fully usable.
When I first read this I assumed it was requesting a change to the existing set of variable types. I am strongly opposed to that.
Now that I understand it's not such a limited, and limiting, proposal I can support it (when some votes get freed up :-( ).
Some of the stuff in there is certainly acceptable as the Access Team asked us to get it out in our messages. Some of the rest I'm less sure about so that's really up to MS to determine.
My guess is that this is acceptable, but I'd be a little more cautious personally. I suspect that in trying to get the allowable message across they may have let something slip. Hence caution. It's very difficult to keep publicising without letting anything NDA slip.
I do know that, as a group, we are very careful about what we put out. We take the NDA side very seriously indeed.