psemianonymous
Programmer
My wishlist is as follows:
1.
Reports natively output to .DOC or other ubiquitous format (.RTF, .PDF). This way, your users can email the reports to their colleagues, without installing the Snapshot Viewer. RTF output is ok, but isn't perfect. I need a PERFECT output, and I DO NOT want to install anything extra to get this output.
2.
Deployment issues resolved, somehow - where you can actually USE the calendar control without problems. Maybe the runtime deployment issues should get its own tick, but since I don't deal with that, too bad. Make your own wishlist.
3.
Built-in search & replace functionality, and better than Name Autocorrect.
4.
First-class support for FTP, HTTP file transfers (obviously http will only DOWNLOAD files). A DoCmd.FTPGetFile would be great, for example.
5.
A Database Backup help-file disguised as a wizard, so I don't have to answer any more questions on this forum about the subject.
6.
Revamp some of the security 'features'. Specifically, I would like to disallow any changes to the default system.MDW file, that way a lot of botched security setups won't get off the ground in the first place. Maybe just an update to the SECFAQ explaining some of the things they left out.
6b.
Allow a user to log out of a workgroup file and re-login to a workgroup inside Access. Sort of like the JET login screen, but allowing you to pick which workgroup file you are connecting over. In fact, just add this to the JET login screen, under 'password'. This would solve a WHOLE LOT of problems. Also: allow a database to have a default associated workgroup file, so that your users who double-click on the MDB will automatically get the 'correct' login screen. I want this feature built-in, not as some sort of addin or 'logon MDB'. I can do that myself; I want this built-in.
7.
Better mailmerge with Word. I don't know how, and I don't know specifically what, but fix something there. Maybe allow Access to 'push' a dataset out to Word instead of 'setting' a dataset in plain view which Word then 'pulls' into the Mailmerge.
8.
Better/CLEANER way to pass data between forms than using the OpenArgs argument. Right now I just jam together all the arguments into one string, then use Split() to cut these up into the 'arguments', then parse through them. This code gets really, really nasty when I can open a form in more than one way--i.e. "this form allows 1, 3 or 5 arguments depending on what mode it's opened in". I have documentation that's a page trying to explain why my code is so nasty. I would love to set up a clean interface, maybe using objects or some sort of 'argument struct', but am totally disallowed because I have to use OpenArgs.
9.
Performance-friendly, server-friendly bound forms. We just take for granted that you're 'not supposed to use bound forms with large datasets'. But that doesn't necessarily have to be. Obviously some parts of it are entirely unmovable (i.e. cannot download entire dataset at once), but the fact that you can't use them at ALL is bad. Maybe have a 'big dataset' bound form mode where you get warning messages if you try and FILTER/SORT/SEARCH the dataset, or try to move to the last record...
10.
Better parameter inputs for queries. Basically build a generalized search form so we don't have to build our own. Over, and over, and over, and over, .... (x100) ... and over, and over. Seriously. Do a search on this forum for 'search form' or for 'parameter query'. If you could combine these into something useful and built-in...excellent.
One thing that people who use parameter queries want is for optional parameters. One thing a lot of people want who are building search forms is for a centralized way to just filter the query. I think this is somewhat tied up in the idea of the Lookup Fields at the table level, but needs to be ... better. And more flexible.
11. First-class support for the OpenFile dialogsolved in newer versions of Access.
If you have comments, feel free to add them. I've been wanting to write about this for a while.
Pete
1.
Reports natively output to .DOC or other ubiquitous format (.RTF, .PDF). This way, your users can email the reports to their colleagues, without installing the Snapshot Viewer. RTF output is ok, but isn't perfect. I need a PERFECT output, and I DO NOT want to install anything extra to get this output.
2.
Deployment issues resolved, somehow - where you can actually USE the calendar control without problems. Maybe the runtime deployment issues should get its own tick, but since I don't deal with that, too bad. Make your own wishlist.
3.
Built-in search & replace functionality, and better than Name Autocorrect.
4.
First-class support for FTP, HTTP file transfers (obviously http will only DOWNLOAD files). A DoCmd.FTPGetFile would be great, for example.
5.
A Database Backup help-file disguised as a wizard, so I don't have to answer any more questions on this forum about the subject.
6.
Revamp some of the security 'features'. Specifically, I would like to disallow any changes to the default system.MDW file, that way a lot of botched security setups won't get off the ground in the first place. Maybe just an update to the SECFAQ explaining some of the things they left out.
6b.
Allow a user to log out of a workgroup file and re-login to a workgroup inside Access. Sort of like the JET login screen, but allowing you to pick which workgroup file you are connecting over. In fact, just add this to the JET login screen, under 'password'. This would solve a WHOLE LOT of problems. Also: allow a database to have a default associated workgroup file, so that your users who double-click on the MDB will automatically get the 'correct' login screen. I want this feature built-in, not as some sort of addin or 'logon MDB'. I can do that myself; I want this built-in.
7.
Better mailmerge with Word. I don't know how, and I don't know specifically what, but fix something there. Maybe allow Access to 'push' a dataset out to Word instead of 'setting' a dataset in plain view which Word then 'pulls' into the Mailmerge.
8.
Better/CLEANER way to pass data between forms than using the OpenArgs argument. Right now I just jam together all the arguments into one string, then use Split() to cut these up into the 'arguments', then parse through them. This code gets really, really nasty when I can open a form in more than one way--i.e. "this form allows 1, 3 or 5 arguments depending on what mode it's opened in". I have documentation that's a page trying to explain why my code is so nasty. I would love to set up a clean interface, maybe using objects or some sort of 'argument struct', but am totally disallowed because I have to use OpenArgs.
9.
Performance-friendly, server-friendly bound forms. We just take for granted that you're 'not supposed to use bound forms with large datasets'. But that doesn't necessarily have to be. Obviously some parts of it are entirely unmovable (i.e. cannot download entire dataset at once), but the fact that you can't use them at ALL is bad. Maybe have a 'big dataset' bound form mode where you get warning messages if you try and FILTER/SORT/SEARCH the dataset, or try to move to the last record...
10.
Better parameter inputs for queries. Basically build a generalized search form so we don't have to build our own. Over, and over, and over, and over, .... (x100) ... and over, and over. Seriously. Do a search on this forum for 'search form' or for 'parameter query'. If you could combine these into something useful and built-in...excellent.
One thing that people who use parameter queries want is for optional parameters. One thing a lot of people want who are building search forms is for a centralized way to just filter the query. I think this is somewhat tied up in the idea of the Lookup Fields at the table level, but needs to be ... better. And more flexible.
If you have comments, feel free to add them. I've been wanting to write about this for a while.
Pete
