I'm trying to find out what my choices are when I'm going to use user (persistent) settings.
In vs Studio this is possible in the properties of your project but I'm getting to know the limits there:
Only values are allowed that can be converted to string.
Collections (e.g items in a Listbox, with a name and value) cannot be saved.
What I would like to know, how do you implement user settings with collections, and how do you make user settings?
Emerion
If I understand correctly I think you're probably looking for serialization, and since you mention values that can't be converted to string I assume that you'd probably want binary serialization.
The System.Runtime.Serialization namespace contains classes to help you with this and here's an article that might be useful: Serialization in the .NET Framework
Related
Of the two choices I have to access the value of a control which is the most efficient?
getComponent("ControlName").getValue();
or
dataSource.getItemValue("FieldName");
I find that on occasion the getComponent does not seem to return the current value, but accessing the dataSource seems to be more reliable. So does it make much difference from a performance perspective which one is used?
The dataSource.getValue seems to work everywhere that I have tried it. However, when working with rowData I still seem to need to do a rowData.getColumnValue("Something"). rowData.getValue("Something") fails.
Neither. The fastest syntax is dataSource.getValue ("FieldName"). The getItemValue method is only reliable on the document data source, whereas the getValue method is not only also available on view entries accessed via a view data source (although in that context you would pass it the programmatic name of a view column, which is not necessarily the same name as a field), but will also be available on any custom data sources that you develop or install (e.g. third-party extension libraries). Furthermore, it does automatic type conversion that you'd have to do yourself if you used getItemValue instead.
Even on very simple pages, dataSource.getValue ("FieldName") is 5 times as fast as getComponent ("id").getValue (), because, as Fredrik mentions, first it has to find the component, and then ask it what the value is... which, behind the scenes, just asks the data source anyway. So it will always be faster to just ask the data source yourself.
NOTE: the corresponding write method is dataSource.setValue ("FieldName", "NewValue"), not dataSource.replaceItemValue ("FieldName", "NewValue"). Both will work, but setValue also does the same type conversion that getValue does, so you can pass it data that doesn't strictly conform to the old Domino Java API and it usually just figures out what the value needs to be converted to in order to be "safe" for Domino to store.
I would say that the most efficient way is to get the value directly from the datasource.
Because if you use getComponent("ControlName").getValue(); you will do a get on the component first and then a getValue from that. So do a single get from the datasource is more efficient if you ask me.
I am trying to create a Visual Studio extension which handles a multi-language content type. Much like some mvc-templates and Django or ASP.NET which a certain part of the code is in another language.
I know that I should use Projection and I already checked Django for Visual Studio extension but the solution there includes creating a Language Service and going to the trouble of creating all bits and pieces related to a code editor. Here I am trying to achieve the same goal just by using MEF.
I know that you can use IProjectionBuffer CreateProjectionBuffer() to create a projection but the question is how to replace the current TextBuffer with the created one and when is the best time to do it.
Also one may expect that if he specifies a base definition of type "projection" like this:
[Export]
[Name("Whatever")]
[BaseDefinition("code")]
[BaseDefinition("projection")]
internal static ContentTypeDefinition WhateverContentType = null;
the received TextBuffer in providers to be of type IProjectionBuffer (after all IProjectionBuffer is inherited from ITextBuffer). Which are not and it seems that a projection base definition has no effect what so ever.
So if I want to rephrase my question in a tldr version:
How and when do you apply an IProjectionBuffer to current view (using MEF and without creating an editor instance)?
So if I understand your question correctly, the answer is "you don't." A IWpfTextView is bound to a implementation of ITextBuffer (or a derived type, like IProjectionBuffer) at creation time, and can't be changed. Even if you could, many other extensions and language services would be most surprised by this and would probably crash.
To address your second question about content types: simply declaring you have a base content type of "projection" doesn't make you a projection buffer. All that really states is you might be creating projection buffers of that type, and when you do you want some extra ITagger support so taggers project through to the source buffers as you might expect them to.
We're looking for a way to document Core Data entities. So far the only real options I've come up with are:
Document externally using UML or some other standard
Create NSManagedObject subclasses for every entity and use code comments
Use the User Info dictionary to create a key value pair that holds a string comment
Option 1 feels like too much extra work and something that will almost certainly be out of date 99% of the time.
Option 2 feels natural and more correct than option 1. The biggest con here is that those comments could potentially be lost if this model class is regenerated using Xcode.
Option 3 feels a little less correct than option 2, but has the added advantage of adding automation possibilities with regards to meta data extraction. For instance, in one of our apps we need to keep a real close eye on what we're storing locally on the device as well as syncing to iCloud. Using the user info dictionary it's pretty easy to automate the creation of some form of artefact which can be checked both internally and externally (by the client) for compliance
So my question is whether it would be inappropriate to use the user info dictionary for this purpose? And are there any other options I'm missing?
Option 2 is what I use every time. If you look at your core data model (something.xcdatamodeld or something.xcdatamodel) you will see something like the picture below.
You can tie your entity to whatever class you want and then put the comments in there. It helps if you keep your entity name the same as your class name to make it obvious what you've done.
Additionally this also gives you the ability to add automation. You can do this by creating custom getters and setters (accessor methods) and a custom description method.
I use option 2 and categories. I'll let XCode generate the NSManagedObject subclasses and use a categorie on each of these subclasses. With the categories I do not loose my changes made in the categories, can document, make custom getter and setters and I am still able to use generated subclasses.
If we speak only about documenting (i.e. writing more or less large amounts of text which is intended to be read by humans) your classes, I'd use the option 2.
If you are concerned with the possibility of Xcode overwriting your classes in the option 2, you may consider creating two classes for each entity: one which is generated by Xcode and always could be replaced (you generally do not touch this file) and one other which inherits from the generated one and in which you put all your customizations and comments.
This two-class approach is proposed by the mogenerator.
Although if you need to store some metadata with the entities which will be processed programmatically, the userInfo is perfectly suitable for this.
I want to be able to change the condition statement of a WF4 Workflow If-Activtity runtime, where the input comes from some sort of user interface as a string. I have read up on how to change a Workflow dynamically, or how to create Activites from code - the problem comes when I get to the point of assigning the Condition-property to the If-activity class. My source is a string. The constructor does not take a string.
Do I have to convert the string to an Expression<bool> first? How do I do that?
This is the string I want to expose
Note: I realize there may be other ways to accomplish what I want, like (1) create code that alters the XAML of the Workflow instead of the objects, or (2) exposing the entire Workflow editor to the end user. Before I go down that road, I want to know if it is possible to do it my way.
You can use a expression like
new VisualBasicValue<bool>("Person.Gender = \"Male\"")
A warning: The Apply Workflow Changes to Workflows you are pointing to is about WF3 and has no bearing in WF4 whatsoever. With WF4 there is no possibility to dynamically change a running workflow instance. That capability is going to be added in the .NET 4.5 framework.
I am creating a front-end for a data collection web application. Operators using the data collection application will log data for a dozen different projects, with each project requiring different fields. There are some common fields (like name, address... etc) but then each project also has custom fields for extra data that needs to be collected. Some projects require dozens of extra fields, while some projects require only 1 or 2 fields. Can anyone think of a "clean" way to handle this situation? I don't want to create an input page for each project, and some people are tossing around the idea of doing UI templates in XML. Any guidance would be much appreciated.
XML would provide a neat solution to your problem. Depending on the user choice, ask the user to fill more fields. From your problem statement its looking that you know how many projects need extra fields and which do not. If you know this data then feed this data into a database and then accordingly generate your form page. However even if the data is available dynamically with the use of an interactive javascript and ajax you can easily achieve a neat solution.