As a practice exercise at my college we have to make a simple room booking system, complete with its own config file. We're not allowed to use the one built into VB.NET (the professor wants us to adapt to not relying on things like that) so I've made my own. This is a sample:
// Config file.
// First column is the variable name that will be used to
// reference the value in the second column. Seperate each
// setting with a new line.
MasterUser Chris
DatabasePath C:\Users\Chris\Desktop\Project.mdb
Comments in the file are pretty self-explanatory. I can parse the file fine, but what I'm having trouble with is making a variable the same name as whats in the first column. For example I need to make a variable called MasterUser and one called DatabasePath that holds Chris and C:\Users\Chris\Desktop\Project.mdb as values respectively. But I have no idea how to make a variable called that.
Any help would be cool, thanks. :)
EDIT: You can't see it from the code view here, but the variable name and value in the config file are separated by a tab :)
You might want to consider using a better format for your configuration file, like XML. This will give you a lot more library support for parsing and searching within the file... that said, in this simple case, it looks like you just need a simple Dictionary(Of String, String) which probably won't make a lot of sense if you haven't learned about Generics yet :)
Basically you can load values in like this:
Dim settings As New Dictionary(Of String, String)
settings.Add("MasterUser", "Chris")
settings.Add("DatabasePath", "C:\Users\Chris\Desktop\Project.mdb")
Then when you want to retrieve a value based on the key in the dictionary, you can do it like this:
Dim master As String = settings("MasterUser") ' master = "Chris"
I hope that helps clear things up.
Well, in the strict sense, you cannot "Make a variable named from file data" in most compiled languages. What you could do is to make a name-value association set (that's a Dictionary in .Net) and add entries to it based on what you read from a file.
However, what most programmers do is to "invert" that logic: as you code reads each line, it just does a series of IF's on the Name to see if it is recognized, and if so then just assings it to the corresponding predefined variable of the same name.
There are formats & libraries specially made for this (like XML, that's why the built in configs use it), but that might still be the kind of thing that you are not supposed to rely on.
Since your configuration file is not compiled into your code in any meaningful way, you aren't going to be able to create a variable (that is, a strongly-typed property or field on a class) dynamically. You have a couple of options.
If you want to keep your configuration file format:
Create a class that contains all possible configuration keys as properties. Give that class a Load() method that knows how to parse a file into the class.
Use a Dictionary -- either the Generics version or good old fashioned System.Collections.Dictionary. You'll retrieve elements with string keys.
If you're willing to change your configuration file format to XML, then you can use Serialization. This frees you from having to maintain a parser, but it requires a little bit more setup.
See here for my answer to another SO's question using nini and where to download it from. Essentially nini is a simple INI read/write library for configuration files. The question that remains to be seen is will your professor allow this inclusion of 3rd party open source?
Hope this helps,
Best regards,
Tom.
Related
How to add a new name in My.Settings?
So far, I've learned how to read and edit values in it, but how can I add another row/name at run-time?
Something like:
My.Settings.AddName.String("foo1")
My.Settings.Save()
My.Settings.foo1 = "fooNew"
I can't see such on the web.. Thanks
EDIT: will be used for the name,text and location of dynamically added buttons.
SeeThisLink
The My.Settings application settings are compiled into your assembly. The properties cannot be altered at runtime because of this. Expecting new settings to be available at runtime through the My.Settings property will not be possible. You would need to resort to more rudimentary techniques like those highlighted by this MSDN question.
You cannot do it at runtime with whats built into my.settings namespace, however its entirely possible. Id love to take credit for this but it has already been answered on stackoverflow.
As long as you know the file path and node name, you can build your own xml parser class to do whatever you want using this very simple example I couldn't write any more clearly:
How to programatically add nodes at certain locations in xml config file
I'd like to know how to configure the location of ObjectStore for JTA. My target is Helidon MP.
Currently directories named "ObjectStore" and "PutObjectStoreDirHere" are automatically created under the current directory. Also I'd like to make sure if we really need two directories in order to manage transactions.
These directory names are the default names for certain directories provided by the Narayana transaction engine, which underlies Helidon's JTA support.
I am not a Narayana expert, but from looking at their source code, it appears that at a certain point they are going to construct an instance of ObjectStoreEnvironmentBean. As you can see, it has a getter method called getObjectStoreDir(). Ultimately this is going to give Narayana the name of the object store directory.
Now, how does this get populated? Again, from looking at the Narayana source code, it appears that this instance will be populated by way of something called a BeanPopulator. Specifically, the BeanPopulator will acquire a default set of properties, and then apply them to the bean under configuration—ObjectStoreEnvironmentBean in this case—and that will provide the name of the object store directory (among other things).
OK, fine, but where do these properties come from? It appears that the default set of properties is located (ultimately) by the AbstractPropertiesFactory class. Specifically, its initDefaultProperties method is going to look for an XML file of a particular kind and load it.
What kind of XML file will it look for? It looks like if there is a System property named com.arjuna.ats.arjuna.common.propertiesFile, that resolves to the path of the XML file in question, it will be used. If there is no such System property, then we can see that the return value from ConfigurationInfo#getPropertiesFile() is used instead.
Somewhat bizarrely, during the build of Narayana (!), that method's bytecode is replaced (!) with a recipe that comes from the pom.xml, and finally there we can see our answer: the return value of this method will be, exactly, jbossts-properties.xml.
That is, of course, a relative path of some kind, or perhaps a classpath resource. Which is it? For that, we have to return back to the AbstractPropertiesFactory class and note how that name is used. We can see that it is sought in various locations via the FileLocator#locateFile() method. The FileLocator#locateFile() method first tries to treat the name as an absolute path (clearly we can see that jbossts-properties.xml is not an absolute path), then as a path relative to the user.dir, user.home and java.home System properties in that order (almost certainly this will not exist either), and finally as a classpath resource. So there is our answer: jbossts-properties.xml, if present as a classpath resource, will be used as the source for where the object store directory should be created and located by Narayana.
Now, what does this XML file look like? It appears that an example file can be found here: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/narayana-jta/src/main/resources/jbossts-properties.xml. You can see that something like this is ultimately where PutObjectStoreDirHere comes from. So I think if you set one of these up in one of the locations detailed above you can get the object store put in whatever place you want.
Things get a little weird, though, because while this answers the question of where PutObjectStoreDirHere comes from, it does not seemingly answer the question of where, simply, ObjectStore comes from. We can see that this appears to be the default value of the objectStoreDir bean property if we look at the source code of ObjectStoreEnvironmentBean again, so my guess here is that there may be some other property involved.
As mentioned before, I'm not a Narayana expert, so it might be best to get in touch with the Narayana folks to find out all the details about all the edge cases here.
According to the Narayana documentation, you can set one of the following system properties.
ObjectStoreEnvironmentBean.objectStoreDir
ObjectStoreEnvironmentBean.localOSRoot
as in
java -DObjectStoreEnvironmentBean.objectStoreDir=/tmp/whatever -jar my-helidon-mp-thing-that-cant-tell-jpa-and-jta-apart.jar
But that only really moves the "PutObjectStoreDirHere" directory. The "ObjectStore" directory is hard coded in Narayana to this:
private volatile String objectStoreDir = System.getProperty("user.dir") + File.separator + "ObjectStore";
And there's no good way in helidon/CDI to plug into the initialization cycle and call ObjectStoreEnvironmentBean::setObjectStoreDir so, we just have to live with that.
The bigger question to me is, why do we have to have some noisy JTA implementation when really all anyone want's #Transaction to do is open and close a transaction. JTA is really not a value add here, or anywhere really.
OK, it may sound fairly straightforward but I'm still not sure how to go about it.
I know it's possible to check file type based on file extensions, using UTIs (e.g. Get the type of a file in Cocoa).
However, I need to be able to get the file type (in more general terms, like "text", "image", "else"), depending on the content.
Is that possible?
Any ideas?
One route forward is to call the file command and parse its output, but that is fairly horrible, and I wouldn't do that as it's slow and you are susceptible to changes in the output.
The file command uses a pretty extensive database of byte patterns to test the contents of the file and I would be tempted to implement my own internal version of it, or use this library (which I think might need some work before it works under OSX).
I'm fairly new to VB.NET, and I've mainly been doing ASP programming up 'til now, and I have a pretty simple question.
I'm creating a program that will copy a selected file to a selected directory, and I want to store recent files/dirs so that they can be selected from a combo box. I was planning to just create a settings with "files" and "dirs", and just store the strings as | separated values (since that's an illegal file character).
Is there anything wrong with this approach, or are there any better methods?
I think your approach is fine as it seems to be simply a local cache of recent directories. You can persist the data in the application at the module level(create a module with a public object essentially is a global variable) but it goes away when the application is terminated.
This article is using a similar approach to what you were thinking although the example is in C#
I'm trying to figure out how to do this as I'm not sure what's the proper way of doing this.
I've got several strings that I want to store/save permanently, even after the application is closed. How should I proceed? Do I read or write from a textfile?
I believe you're looking for a feature known as Application Settings. This feature will take care of storing settings between instances of the application. The manner in which it stores settings is ClickOnce and User aware so it takes much of the problems out of the picture.
Here's a link to an overview on the topic
http://msdn.microsoft.com/en-us/library/c9db58th(VS.80).aspx
Use My.Settings
Yes, you might store it in a simple text file or use a settings file.
Take a look at Application Settings:
http://msdn.microsoft.com/en-us/library/0zszyc6e.aspx
I store what I need in a plain text file. I use my own format: First line: lenght of the array or the number of bytes/lines the data needs to be stored. Second line: data types. third line: directories or path info. At the end I store the data.
That's because programming languages can read by characters or by lines. C++ considers either whitespaces and lines.
SQL or Access is when you need to store more complex data than just strings or arrays.
Yes, I'd store it in some form of text file, then you can read it on load. It's very easy to implement in Visual Basic and you might even find some samples in Codemonkeys or similar. I'd avoid using the registry. Of course if you want, you could also use some sort of database (Access, SQLITE, etc.) to store the values. But that depends upon the type of data and how much do you need to read/write from it.
yes you can write to a text file, or try SQLite, which can let your VB program have database capabilities.
http://www.google.com/search?hl=en&q=visual+basic+sqlite&btnG=Search