I would like to maintain a list of all of the strings entered into a ComboBox across all uses of an application on a given PC, for use as the AutoCompleteSource for that ComboBox, i.e., I enter in "Fred" in the ComboBox, commit the data, close the application, reopen the application, reopen the ComboBox, type "F", receive the suggestion "Fred".
Assuming I already have in place code to create and maintain such a list in memory and add new elements to it as they are entered into the ComboBox, etc., what do you suggest as the best way to save/load this data in between sessions?
Possible complicating factors: This application will be deployed via OneClick deployment, and will search for updates online every time the application starts. I would prefer that if the application updates, the list still exists after the update has completed.
Thanks for your help.
Depending on your access level, storing them in a flat file seems the easiest choice.
To read the list of options, read the file and return an empty list if it isn't there.
To add an item, create the file if it isn't there and then append the option.
That means you don't send an empty file with your updates, so the data survives.
It appears that you could put the file in the Data Directory or use Isolated Storage.
I would simply use the built in User Settings (My Project > Settings > Pick "User" for the scope of the setting); they are extremely easy to retrieve and update. And although I haven't done extensive testing, I believe they remain through application updates.
Does your application use a database? If so, that would be another option for permanent storage.
Edit
If you decide to go with the User Settings option, here is a new question that addresses an issue with those settings and ClickOnce.
Related
I need a person to be able to input information into a field in a PDF then later be able to select and copy all information from that field with a single click so they may paste it into another field on a website.
Purpose. I am trying to create a master application which people with disabilities may complete and use as a simple way to fill out other applications. I don't believe I can create an autofill ability which will be useful for the thousands of different methods of job application but I want the human to be able to select the correct field then, in as few clicks as possible, copy information from a field in the PDF and paste it into one they deem as appropriate in another application.
I am an idiot, this is a passion project.
It may be simpler depending on user cases to work inside the browser framework. Here is totally non typical usage for copy data from local personal html into remote form. IT depends heavily on the remote site accepting it can be embedded as if a local frame thus not useful for generic use but may work for controlled caseload's
I have a split database and I have duplicated front-end file to make multiple copies for different users. Every-time a change is made on one front-end form, I want the other forms in other front-ends to always drop changes. How can I trap this write conflict to always drop changes maybe through VBA if possible?
Not quite sure what you mean by "drop changes" - the frontend should never be redesigned during normal use.
You must distribute a new copy of the frontend to the users.
A smooth and proven method using a shortcut and a script is described in my article:
Deploy and update a Microsoft Access application with one click
(If you don't have an account, browse for the link: Read the full article)
Edit:
If it is the data that is updated by several users, and you update via VBA, you may study another of my articles:
Handle concurrent update conflicts in Access silently
Though simple to use, the code is a bit too much to post here. It is also on GitHub:
VBA.ConcurrencyUpdates
I am working on a VSTO-Excel-Addin (VB.NET) that we are about to sell to different companies.
The addin will (hopefully) be used by a couple of users of each customer. We are using ClickOnce for a web-based deployment.
The addin provides some default-settings - that is no problem with the app.config. User-specific Settings are also working fine with ClickOnce.
However what makes quite some headache is how to store settings per customer. Database-connectionstrings for example cannot be stored on the application-level but it would also be painfull for all users to change the Connection-string manually. What I would imagine is another layer (per Company) where this sort of Setting can be stored.
One alternative would be to create one VSTO-Project per customer but this would bring a lot of disadvantages since we are updating the addin quite regularly.
I would be happy about any ideas!
Regards,
Julian
I would show Excel's built in connection properties dialog and let each client configure this themselves.
You really shouldn't be distributing connection strings for all your clients as part of a shared package. It'll be a maintenance nightmare.
http://office.microsoft.com/en-nz/excel-help/connection-properties-HA010175443.aspx
What about storing the settings as custom properties in Book.xltx and copy it to
C:\Users\username\AppData\Roaming\Microsoft\Excel\XLSTART
This is how you can programatically read and create Custom Properties in Excel.
When a new workbook is created then all the properties from Book.xltx will be available for New Workbook as well. But this solution may not work if the existing workbooks are opened so yo might have to explicitly add these properties when any existing workbooks are opened using the above solution.
Ok, I think I understand the problem. :)
How about storing all the settings in an offsite database that you maintain and using a webservice to allow the settings to be read and set and giving each client a unique license number that would allow them to access this webservice.
That way the individual users would only need a license number to set it up.
I'm beating a dead horse here, but I still haven't found the answer I am looking for. I am throwing together an Access Database that deals with lockout procedures for our various machines at work. I have a continuous form setup so that it dynamically populates based on various complex/machine criteria. Since only portions of the machines need to be locked out at a given time, it is necessary to select the various devices from the list that was populated dynamically. When users select the various devices that they wish to lockout, they will then be able to automatically print tags for the selected devices. Which is where the unbound checkbox conundrum comes in... Yay!!!
Since it is possible for multiple users to be using the database at a given time, I don't believe that binding the checkbox to a yes/no selection within my table is the correct path to take. This is due to the fact that having multiple users picking various devices would result in additional/unnecessary tags being printed out to each user. I know that it's possible to have an unbound checkbox within a continuous form, but I have not come across any sample code that has this functionality.
If there is another path that I can take, please offer any suggestions as I am an Access novice, and am open to new ideas.
EDIT
I should mention that the database will reside within Citrix. I am not sure if this affect anything, but its worth mentioning at least.
I am assuming that you are using a client server setting, where the application file resides on a local machine. (Or on a local instance in the case of RDP / Citrix)
In that case, you can have a local table to save the checkbox information without causing any conflicts between users.
You will be using a bound checkbox, so problem solved.
What I'm trying to do is seperate my existing MS Access application into a front-end (which will run locally on a user's machine) and backend (which will be hosted on a networked file server) and allow users to choose between "read-only" and "write" modes. The idea is that only one user can use the "write" mode at a time, thus preventing the same piece of inventory being allocated to mutliple customers. My problem is that the application currently handles concurrency by requiring users to open a .bat file which only allows them to enter application if a .ldb file does not already exist (there is no read-only mode currently), so I need to prevent users accessing the production data in "read-only" mode from creating a .ldb file and unessarily blocking out other users.
The biggest challenge to implemnting this is that users must have write access to the temporary tables in the MS Access (.mdb) file installed locally. I have tried to implement this using a linked table, but I'm not sure how I can control when records become locked using linked tables (which creates a .ldb file).
You could change the sharing setting back to Exclusive Mode. Then only one person can access the file at a time. Check out this link and the other sharing options you have.
http://office.microsoft.com/en-us/access-help/set-options-for-a-shared-access-database-mdb-HP005188297.aspx
Side note: Yikes. Using Access in a shared network environment is not fun. I hope nothing important/time sensitive/secure is in this file. The .ldb file not being deleted and blocking other users is something that I use to see happen regularly in this situation. I believe splitting the Access file into a front-end and back-end like you've done is the first step. Then using linked tables to a SQL Server database can help resolve these issues. But if you're going to this level of effort you may want to consider dumping Access and get a COTS product or create a new application.
Depending on which version of Access you are using, theres alot of flexibility in the UI developement. In other words, this sounds more like an "interface" issue as apposed to a "database" issue. Given everybody is able write to a table, you should be able to check in somewhat real time (performance can be an issue with larger datasets), whether a particular has been added to inventory or not.
They I handled this problem is have two tables, an incomming and outgoing log, and set up a query that did the math against the inventory list on the amount of products. And like a general ledger, select set amount of time to "close the log" (monthly, quarterly) so that the query is not taking into account stuff that happened two years ago.
If you need more help with Access related stuff, Access Monster is a good forum site that deal with nothing but access.
My problem is that the application currently handles concurrency by requiring users to open a .bat file which only allows them to enter application if a .ldb file does not already exist (there is no read-only mode currently), so I need to prevent users accessing the production data in "read-only" mode from creating a .ldb file and unessarily blocking out other users.
--> If every user has his own copy of the front-end on his own machine, you'd have to check the .ldb file of the back-end.
I guess it would be easier to give everyone write access to the backend and manage the actual writing programmatically with a "locked by User X" field in the backend:
You said:
preventing the same piece of inventory being allocated to mutliple customers
If this is the only reason for putting all users but one in read-only mode, you could put a "locked by User X" field on the inventory table. If someone starts to modify (or even opens) a piece of inventory, update the record with his user name, and delete the user name again when he's done.
If another user tries to open the same piece of inventory as well, the name of the first user will already be in the "locked by User X" field, so you can put the second user in read-only mode.
If the inventory pieces are not the only problem and all the other users really are not allowed to change anything as soon as someone else already is editing, you can create a new table with only one column and one row and use this as the "locked by User X" field. As soon as there is a user name inside, you can put everyone else in readonly mode.
No matter how you do it, you will have to provide some kind of admin menu, so if someone's front-end crashes while editing, someone else needs to be able to unlock this user's locked data (=delete his username from the "locked by User X" field).