Nested Reference of Application Settings in Function App - azure-function-app

Is there a way to reference an Function App Application Setting in another Application Setting. In the example below I have an Application Setting with an EventHubKey. The content of that setting is inserted into the second Application Setting called EventHubConnectionString.
EventHubKey: wHBhcHdvga28JbvfWnZgmFt94RB+RAZfP+Cq0WtUooiM=
EventHubConnectionString: Endpoint=sb://myevh.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=ReferTo:EventHubKey;EntityPath=e1

Related

How a macOS document-based app start itself?

I am learning the document-based app architecture of macOS app development, but am confused about it.
I created a document-based app in Xcode. The app template created a simple document-based app. It can run, and will create a new document automatically when it is run.
My question is: How does this app start the document architecture? I suppose that there should be some code like the following:
NSDocumentController *docController;
docController = [NSDocumentController sharedDocumentController];
[docController newDocument:self];
But I can't find any such code in the created app. The - (void)applicationDidFinishLaunching: method in the app delegate is empty. Also, there is not any NSDocumentController object in the main nib file.
So, how does this app know that it should use the document architecture, initialize a NSDocumentController, and then create a new document?
how does this app know that it should use the document architecture, initialize a NSDocumentController, and then create a new document?
I’m unclear about the inner workings of Xcode, but it appears that in the app’s info.plist CocoaNSDocumentClass has to be set to Document and Role has to be set to Editor (or Viewer, None, or Shell) in order for the document to be created. In your demo try deleting either one or both of these lines in the plist and see if the app still works. Both settings are located on the second level of Document types. In my experience, deleting either of these lines breaks the app and restoring the correct setting fixes it. In a programmatically created document-based app (no nib) and compiling with Terminal the following errors are generated when I go inside the bundle and run the executable after deleting one or the other info.plist settings mentioned above.
2020-02-11 19:31:48.294 nsdoc_demo[1606:658926] NSDocumentController Info.plist warning: The values of CFBundleTypeRole entries must be 'Editor', 'Viewer', 'None', or 'Shell'.
2020-02-11 19:38:46.355 nsdoc_demo[1748:680819] -[NSWindowController loadWindow]: failed to load window nib file 'Document'.
Xcode (with Document.xib) generates the following error when CocoaNSDocumentClass is not set:
2020-02-11 16:22:03.022602-0600 docExpt[1166:428702] The DocumentType type doesn't map to any NSDocumentClass.
In my experience the source code can be ok, but if the info.plist is not set correctly a document-based app won’t work as expected.

UWP Using Pages from different Project

Is it possible to have all pages in a different project from where the app.xaml/cs is in?
I tested this by creating a new "Class Library (Universal Windows)" or "Windows Runtime Component" project, then I created the new pages in those projects.
After I add this project as a reference to the main UWP app and call the page(s) in the "rootFrame.Navigate(typeof(MainShellView), e.Arguments)" I get the exception
system.accessviolationexception attempted to read or write protected memory
Is it possible to have the pages, controls in different projects than the UWP main project and use them as references?
You will need to keep an empty/dummy MainPage.xaml page in the main project as there is a hard-coded reference to it in the project system. With that in place you can load all your pages (incl. the initial start page) from other projects that you are referencing in the solution.
I will log a bug on the hard-coded dependency on the existence of "MainPage.xaml". Thanks for reporting!

How can I automatically run an AppleScript when Safari.app starts?

Basically I want make sure I execute a custom written .applescript every time Safari is opened.
I tried adding the script to the "~/Library/Scripts/Applications/Safari" folder but that doesn't seem to automatically do it.
As a workaround I can probably just write an AppleScript that both starts Safari and runs my custom stuff. I just wanted to check whether there's a cleaner way of doing this.
Putting stuff in the ~/LibraryScripts/Applications folder just makes them available when the particular application is active.
In addition to your alias that runs the script and Safari, you could use some AppleScriptObj-C in a background application (maybe run via login items) that registers for NSWorkspaceDidLaunchApplicationNotification notifications to get the names of applications as they are launched. This would also have the advantage of seeing when Safari gets launched other than from your alias, such as via various document links (Mail, PDFs, etc):
use framework "Foundation"
my addObserver:me selector:"appLaunchNotification:" |name|:(current application's NSWorkspaceDidLaunchApplicationNotification) object:(missing value)
on appLaunchNotification:notification -- an application was launched
# notification's userInfo contains the application that was launched
set applicationInfo to NSWorkspaceApplicationKey of notification's userInfo -- NSRunningApplication
set appName to (localizedName of applicationInfo) as text
-- do your thing depending on appName
end appLaunchNotification:

Add a new category to the navigation bar of the windows files explorer

How can I programmatically add a new category to the navigation bar of the windows files explorer. I mean something like this (For Example)
It is namespace shell extension. NSE must be registered in Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\Namespace\NSE_CLSID. Also it must implement IPropertyStoreFactory and must return True when system requests value of PKEY_IsPinnedToNameSpaceTree property.

User Specific App Settings

I have started working with server side app settings and it would appear the default mechanics for a shared app is to save the app settings across the entire project scope; so if an individual makes changes to the app settings, those changes are reflected for all future users. This is not the ideal use in my specific case. I would like it if I could have different settings for each user, without them each adding separate instances of my custom HTML. Is this possible using server side settings, or will I need to look into using cookies to save the settings on each user?
Note: I've read the documentation on app setting scope (https://help.rallydev.com/apps/2.0rc1/doc/#!/guide/settings-section-define-scope) but it doesn't appear as though "user" is an option.
Thanks!
Conner, you're making a good argument for User-level settings for an app.
Unfortunately, we don't support that currently. The settingsScope option in AppSettings only supports the values app, project, or workspace.
Creating an instance of the app for each user (such as on their individual dashboard) is the best alternative I can think of. But as you mentioned, this is not ideal for you.
I have solved this issue by prepending the user ObjectID to each setting value before I save or load it from the Rally servers. Here is the code for my user settings set/get functions:
setUserSetting : function(settingName, settingValue, callback) {
var settings = {};
settings[App.getContext().getUser().ObjectID + settingName] = settingValue;
App.updateSettingsValues({
settings : settings,
success : function() {
App.setSettings(Ext.Object.merge(App.getSettings(), settings));
callback();
}
});
},
getUserSetting : function(settingName) {
return App.getSetting(App.getContext().getUser().ObjectID + settingName);
}
BTW, it seems kind of strange that I have to save the settings in the way I have. The "updateSettingsValues" function sets the settings on the next load of the app and the "setSettings" function sets it for the current runtime of the app. It's a strange way to have to do it, but it works.