I am not sure how to use Application Setting with custom user types.
For example, in a time tracking system, I would like to have an application setting (with application scope) that says how many hours a day an employee must account for. There is a custom user type, TimeQuantity, with some factory methods and a constructor with a signature of TimeQuantity(double, TimeSliceUnit), where the unit is just an enum.
I can get the settings designer to recognize the TimeQuantity type, but am at a loss as how to provide the setting value (8d hours, here).
Must I create some sort of settings provider? Build the object outside of the designer? Roll my own settings infrastructure?
Cheers,
Berryl
I was just battling the same issue. As far as I can tell, visual studio doesn't allow you to browse to a type in your current project; you can only browse to types in a referenced assembly. However, you can type the fully qualified name of the type you want to use in the settings 'Select a Type' dialog box like shown below. Note that this won't work until your project has been built with the type you want to reference already included. (Same is true with referenced assemblies.) Hope that helps!
Related
I'm working on a Xamarin Forms app, using a .NET Standard library. I've used the TranslateExtension as mentioned in the docs. I've added three resource files:
AppResources.resx (with matching code-behind file, auto-generated)
AppResources.nl.resx (Dutch translations)
AppResources.fr.resx (English tranlations)
When debugging the (UWP) app, I can't get the default culture (English) to be displayed. The following line returns null:
ResMgr.Value.GetString(Text, ci);
I've add some lines for debugging, and the other two languages do return the translated value:
ResMgr.Value.GetString(Text, new CultureInfo("nl")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("fr")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("en")); // returns null
What could possibly be the cause of this?
Things I've tried:
I've copy-pasted the key across all resource files, so I've ruled out misspelling the resource key.
I've tested "en-GB", "en-US", CultureInfo.InvariantCulture.
I've changed the default lanuage in the appxmanifest from en-US to en.
On UWP, watch that your resource name does not have a period in it..
You also likely need to tell the UWP project what its default language is. This can be done in the .csproj in the top <PropertyGroup> element (the one with no conditions) by adding <DefaultLanguage>en-US</DefaultLanguage> (using the proper culture for your scenario).
Don't forget to set the [assembly: NeutralResourcesLanguage("en-US")] as well for the assembly containing the resources - this is required for .NET Standard 2.0 and likely PCL.
Well it seems like you've got resx files for "nl" and "fr" (which you've said works fine) but you don't have one for "en". If you're trying to get the English value like that, I would think you need an "en" file the same way you do for "nl" and "fr"
I noticed that you told about NET Standard library
ResourceManager.GetString started giving null for new entries after moving from PCL to .NET Standard
I also observed that the file AppResources.Designer.cs disapeared from the Solution Explorer (but I don't know how, was still considered) and, in the VS res editon of AppResources.resx, Access Modifier was No Code Generation.
Here is what I did to fix that:
I double-clicked on AppResources.resx and set Access Modifier to Internal or Public
In .NET Standard you may no longer be able to see "View Code" from resx files; so, I righ-clicked on AppResources.resx-> Open With -> Source Code Editor and copy the new created entries to all the others *.fr (also *.nl in your case) ...
NOTE
In the context menu you should see Run Custom Tool. You may need to delete the old AppResources.Designer.cs and do "Run Custom Tool"
Don't forget to clear the solution (or olny UWP and the standard library), close VS, delete all .\bin and .\obj and restart VS. This to ensure your issue is fixed or not using the very very new generated true code :)
When automating excel using the Excel Interop API, I can easily do a range search using the method Range.Find. I am passing through the LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase options for the Find. This as noted by the MSDN documentation, persists the values passed into this method into the user settings, so the next time that the user opens the find form, the options will be selected which I used in the Range.Find method.
I need to persist the values of the find options before and after I do the programmatic find. So I want to capture the current find options, then do the Range.Find, and then set the find options back to the options that were set before my search. However, I do not see that the find options are publicly accessible. Any ideas on how to get these?
I'm basically looking to retrieve current find option values for LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase.
Update
The most interesting thing I could find so far is that you can access the Excel Application dialogs - Dialogs Interface. So here, I can get access to the FormulaFind dialog, which is slightly different than the Find and Replace dialog, though may lead to some of the properties I'm looking for. I haven't had any luck, but perhaps there's a way to access the properties through this form using reflection. I'll keep trying something with this.
// xlDialogFormulaFind, xlDialogFormulaReplace
Excel.Dialog dialog = this.Application.Dialogs.Item[Excel.XlBuiltInDialog.xlDialogFormulaFind];
Well, I am not sure if you'd consider this approach, but I'll give a shot here in case it might be helpful.
What I would do is, I'd create a registry key holding the values you wanted to persist. I could then call RegistryKey.GetValue(valuename) to retrieve values, provided that there's no exceptions thrown.
As long as that registry key stays there, unchanged, and you have enough privilege to access registry key, you should be able to always get the same values.
Wish we could really use application settings here, which would make it easier, but, well, as you might have known, vsto add-in doesn't like it, according to this article.
You cannot use application settings in an unmanaged application that
hosts the .NET Framework. Settings will not work in such environments
as Visual Studio add-ins, C++ for Microsoft Office, control hosting in
Internet Explorer, or Microsoft Outlook add-ins and projects.
Hope this helps.
I'm in VS2010, in a new Word Add-In project. This is my first attempt at Word development using VSTO. The example I'm trying has this line:
Document vstoDoc = Globals.Factory.GetVstoObject(this.Application.ActiveDocument);
But when I add this line Visual Studio says it can't find "Factory". Indeed, it's not in Intellisense.
I've got references to:
Accessibility
Microsoft.Office.Interop.Word
Microsoft.Office.Tools.Common.v9.0
Microsoft.Office.Tools.v9.0
Microsoft.Office.Tools.Word.v9.0
Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0
Office
and all the usual System references.
Where am I going wrong and why can't I get to "Factory"?
stdole
That example looks a bit weird to me. Never seen that sort of reference before.
Generally, with Vsto, you hook into EVENTS on, say, the main Word App object.
Then, from within the event, you usually are passed a reference to the particular DOC object that the event is occurring for (say, being opened or saved, etc). In that way, there shouldn't be any need for using the "globals" object or the "factory" object, whereever they might be.
What method is that code in? A little more context might help.
I think the recommended way of doing this is:
Globals.ThisAddin.Application.ActiveDocument
In other words, can I count on a control ID as a reliable identifier?
From some reading I've done, it sounds like .NET controls can have control IDs that change with every run, is this so for Win32 apps as well, or are they something that's hardcoded in the source?
The window/control in question is actually an Internet Explorer dialog if that helps.
In general win32 dialog resource IDs do not change when you run the app. However, they are internal implementation details and as such they are subject to change whenever an update (patch, service pack, major release) to the application is made.
In general all of IE's dialogs use hard-coded control IDs. There may be some that are dynamic. If you give the specific control I might be able to give you a better answer.
The answer is "it depends on the circumstances, but in the majority of programs, these will not change across multiple executions." In general, a control ID or resource ID will be the same across every execution of the same program.
In most implementations, resources are stored in the resource section of the PE executable and are assigned a resource ID within that data structure. Usually, the developer specifies the resource in a .rc file.
The exceptional case is via APIs such as CreateDialogIndirect() which allow IDs specified through the API at runtime. Such dynamic creation is uncommon, however. Consistency of resource IDs and control IDs is the expected condition, so even in the case of the CreateXXXIndirect() API, users of the API would be ill-advised to chose a varying ID.
Microsoft has spent years trying to deal with applications which embed assumptions about internal windows implementation details. One of the biggest causes of compatibility problems for IE8 was caused by applications which made assumptions about the window order of IE controls. When the UI was changed in IE8, the controls moved and a number of browser plugins broke hideously.
In general you should never ever make assumptions about controls in an application that you didn't write - your code WILL break in the future (not might break, will break).
As a general rule, no they don't change between runs. Control IDs are usually specified with a dialog template, and that's a static resource compiled into an .exe or .dll. Controls can also be created using a regular call to CreateWindow or CreateWindowEx. In such cases, the ID is usually a constant, but it could be anything in principal (even a random value).
In any case, if you're planning to muck around with a dialog in another application, then you are asking for trouble. Control IDs can and do change between different versions of a program.
It depends on the control. Controls that are dynamically created could have a different ID every time they are created. Controls based on static dialog resources will have static IDs.
Even if a dialog is backed by a dialog resource template, controls can be added dynamically at runtime and those controls could have dynamically generated IDs.
Depending on your intent, it may be acceptable to store and reuse it for future lookups or traces; but in general it isn't safe.
If the window is based upon a dialog template, items declared in the template generally don't change. It is perfectly safe under typical circumstances to use these as identifiers.
Sometimes the window class name or a portion of it can be used as an identifier instead, depending on the window host.
If the dialog is one of the standard prompts from internet explorer, you may want to use text stored in adjacent controls or the dialog caption as additional verification info (if localized versions of IE are not an issue). If the dialog is a window that embeds an instance of MSHTML/IE; none of these options may be viable- but you can use OLE accessibility to get at the document shown and then browse the DOM from there.
I was wondering how Visual Studio associates MFC CDialog derived classes with their corresponding dialog resources. I'm not interested in how the connection is made at run time (as asked here), but rather at design time.
When I add a message handler to a dialog, how does it know which class to add the handler to.
Also, is it possible to have several CDialog derived classes associated with the same dialog resource and vice versa?
I have searched the project directory for the IDD_SOMEDIALOG string but have only found it in SomeDialog.h, resource.h and Project.rc in the expected places so I guess it somehow deduces the connection from those files, most likely the enum in SomeDialog.h:
// in class CSomeDialog:
enum { IDD = IDD_SOMEDIALOG };
I'm asking this mostly out of curiosity.
It depends on what version of dev studio.
In VS6 it was all kept in the CLW (Class Wizard File).
In newer versions of dev studio it doesn't use the CLW anymore and I don't know specifically how it knows, but i suspect its a live parsing instead of using a cached CLW.
As for having multiple derived dialogs using the same resource, it can be done manually. You can duplicate the created class files and rename them and remove the enum from header and edit the use of the IDD enum in the source file to be the actual dialog resource id (IDD_SOMEDIALOG).
AFAIK Dev Studio will only 'happily' handle one class to a dialog at a time. In my experience trying to re-use a dialog resource like this just ends up in a bit of battle with MFC & Dev Studio since they were not intended to do this.
To add to Ruddy's answer:
I noticed that some of my dialog classes in which I replaced the enum { IDD } with static const int IDD was not any longer associated with its dialog resource. Reverting to the enum re-associated them. So it seems that visual studio parses the source code to determine the relationships.
As for resource sharing, it would be ambiguous as to which class should receive the event handler code. Class sharing seems to be be impossible since it relies on the IDD which can not be assigned to a IDD_SOMETHING and IDD_SOMETHING_ELSE simultaneously.