profile
viewpoint
Adam Krantz akrantz @microsoft Seattle, Washington

akrantz/Chakra-Samples 0

Repository for Chakra JavaScript engine related samples.

akrantz/ChakraCore 0

ChakraCore is the core part of the Chakra Javascript engine that powers Microsoft Edge

akrantz/ChakraCore-Debugger 0

Debugging companion library for the ChakraCore JavaScript engine

akrantz/ChakraCore-Debugger--old 0

Debugging companion for the ChakraCore JavaScript engine

akrantz/create-react-app 0

Create React apps with no build configuration.

akrantz/DefinitelyTyped 0

The repository for high quality TypeScript type definitions.

akrantz/edge-diagnostics-adapter 0

Microsoft Edge Diagnostics Adapter is a protocol adapter that enables tools to debug Microsoft Edge using the Chrome DevTools Protocol.

akrantz/Excel-Custom-Functions 0

Learn about custom functions in Excel.

akrantz/Excel-Custom-Functions-JS 0

Write your own functions in Excel using JavaScript.

akrantz/generator-office 0

Yeoman generator for building Microsoft Office related projects.

issue commentOfficeDev/Excel-Custom-Functions

Add custom functions to existing visual studio generated add-in

This is difficult to document as there are various changes. I suggest using Yo Office to create a new project for Excel Custom Functions and then comparing the differences against your project.

Primarily you'll see differences with the webpack config which allows for generation of the json, and the manifest changes for the custom function additions.

Debugging for custom functions is different than taskpane since it runs in a separate runtime. This is designed for debugging using VS Code for the custom functions instead of using Visual Studio or browser devtools for the webview where the taskpane runs.

chucklay

comment created time in a month

create barnchakrantz/Excel-Custom-Functions

branch : taskpane-master

created branch time in a month

issue commentOfficeDev/Office-Addin-Scripts

ESLint files Pattern

Do you have your sources files in an src folder? Do they have a .js extension?

abimaelmartell

comment created time in a month

CommitCommentEvent

Pull request review commentOfficeDev/vscode-debugger-extension-for-office-addins

Check that user is running Windows 1903 or greater

 export class EdgeDebugAdapter extends ChromeDebugAdapter {          // Check that debug adpater executable exists         if (!fs.existsSync(adapterExePath)) {-            if (utils.getPlatform() == utils.Platform.Windows) {+            if (utils.getPlatform() == utils.Platform.Windows && os.release() >= '10.0.18362') {

You shouldn't check versions using a string. "8.1.12345" is greater than "10.0. 18362"

TCourtneyOwen

comment created time in a month

Pull request review commentOfficeDev/vscode-debugger-extension-for-office-addins

Check that user is running Windows 1903 or greater

 export class EdgeDebugAdapter extends ChromeDebugAdapter {          // Check that debug adpater executable exists         if (!fs.existsSync(adapterExePath)) {-            if (utils.getPlatform() == utils.Platform.Windows) {+            if (utils.getPlatform() == utils.Platform.Windows && os.release() >= '10.0.18362') {

You really want to check each component of the version separately. There's probably a library that can parse the numbers between the periods and do the comparison properly. This will work but it doesn't reflect the best practice when dealing with version numbers.

TCourtneyOwen

comment created time in a month

issue commentOfficeDev/Excel-Custom-Functions

Reported invocation cell doesn't match the actual invocation cell when the function is copied.

@noon-otter I believe the issue may be that you need to capture any info in the invocation object, because after a fetch call, you can no longer rely on the data in the object.

I'm not clear why you are comparing invocation addresses and re-fetching "until the invocated address is stable".

Rather than share your code, you might see if you can clone this repository and make changes to provide a simple example to reproduce the issue. If you can, create a new branch, commit the changes to the branch, and push it to your fork of the repository, then others can use that as the example to investigate the issue.

I would think that the input to the custom function shouldn't depend on the address where it was invoked. If it does, perhaps you could explain why. When you drag the cell, you may be seeing effects of how the various cells are recalculated. Typically the custom function wouldn't want to depend on the recalc behavior. In your scenario, it seems like it does for some reason, and it would be helpful to understand more about why that might be the case. By re-fetching until it is stable, it seems you are probing to know when the recalc has finished. If there is some way to provide more insight into this, it might help better understand what is going on.

noon-otter

comment created time in a month

issue commentOfficeDev/Excel-Custom-Functions

Custom Function JSON Autogenerate - Breaking with Non-Custom Functions?

The plugin should allow for other functions. We've tested cases for other functions being used without the @customfunctions tag. Is that error from a different plugin, e.g. Terser?

thunter05

comment created time in 2 months

issue commentOfficeDev/Excel-Custom-Functions

Is there a way to have multiple custom functions with different namespaces?

The JavaScript function name cannot contain the period, but the name in the metadata certainly can. These names do not have to be the same.

I'd like to call out that the Yo Office template for custom functions has a webpack plugin that can generate the custom function metadata from the JavaScript/TypeScript source. It will generate the metadata name from the JavaScript function name but you can override this in the @customfunction tag. We made sure to allow for periods in this name for just this reason. The webpack plugin can also generate the associate calls automatically(). If you want more info about using this, I'd be glad to assist.

Otherwise, you can call associate yourself.

CustomFunctions.associate("FOO.CALCINTEREST", fooCalcInterest);

wh1t3cAt1k

comment created time in 2 months

issue commentOfficeDev/Excel-Custom-Functions

Is there a way to have multiple custom functions with different namespaces?

The name of the custom function can have a prefix, so instead of the function being CALCULATEINTEREST(), the actual function name can have a period and be FOO.CALCULATEINTEREST() and BAR.CALCULATEINTEREST(). If you have the namespace as "CONTOSO", then these would appear as CONTOSO.FOO.CALCULATEINTEREST() and CONTOSO.BAR.CALCULATEINTEREST().

wh1t3cAt1k

comment created time in 2 months

issue commentOfficeDev/generator-office

Unable to start the dev server - stdout maxBuffer length exceeded

I'm not sure why this is happening, and it would help to know which OS you are using, which Node version, and perhaps others things, but I can offer some suggestions to help.

First, you might try rebooting, as maybe something is in use.

Second, try running npm run dev-server to start the dev-server by itself. Any difference?

If you have the dev-server running and then do npm start, then it will detect it is running and won't try to start it.

I don't know if this will make a difference, but I like to run the dev server in VS Code so it stays running while you close and relaunch Excel. If you open the folder in VS Code, you can then do use Run Task from the Terminal menu and choose Dev Server. You can then use Start Without Debugging to launch Excel.

(VS Code cannot debug the WebView control running in Excel so you have to use a different mechanism to debug it. You might still find using VS Code convenient as an editor.)

It would be interesting to know if having VS Code run the dev-server has a different result.

zzzaaaccc

comment created time in 2 months

issue commentOfficeDev/generator-office

Webserver stops soon after starting in new project on Mac

npm run start:web will ensure that the dev-server is running. npm start will do the same but for "desktop" apps as a target will also sideload the add-in which will launch the Office app.

In any case, once the dev-server is running, you can go to the browser https://localhost:3000 to see something. The manifest contains the actual full url which Office or the browser can use to load the add-in. For development this is https://localhost:3000/taskpane.html (I believe -- this is off the top of my head.)

You could likely go back to a previous webpack / webpack-dev-server version which doesn't have the problem. Or once there is a version available that has the fix, you can update to it.

RyanHedges

comment created time in 2 months

issue commentOfficeDev/office-js

Running `npm run build` creates and then deletes functions.json file

If you clone the https://github.com/OfficeDev/Excel-Custom-Functions repository and check out the "yo-office" branch, then run npm install and npm run build, this should build successfully.

It would be good to see what is different with the package.json dependencies and the webpack config.

Also, did you start with the React taskpane template and then add custom-functions to it? The package.json name appears to be office-addin-taskpane-react. That's fine, but I am just wondering.

Adding @TCourtneyOwen for visibility.

areed1192

comment created time in 2 months

delete branch akrantz/Office-Addin-Scripts

delete branch : update-lerna-to-3.21.0

delete time in 2 months

push eventOfficeDev/Office-Addin-Scripts

Adam Krantz

commit sha 23477229b2a81d393ccf083f9242247e86cd764d

update lerna to 3.21.0

view details

Adam Krantz

commit sha 594b7738aaf70faaa5b2317cce7c37ec833c411a

Merge pull request #283 from akrantz/update-lerna-to-3.21.0 update lerna to 3.21.0

view details

push time in 2 months

pull request commentOfficeDev/Office-Addin-Scripts

update lerna to 3.21.0

I'm hoping that it will but I don't know yet.

akrantz

comment created time in 2 months

PR opened OfficeDev/Office-Addin-Scripts

Reviewers
update lerna to 3.21.0
+474 -1086

0 comment

4 changed files

pr created time in 2 months

create barnchakrantz/Office-Addin-Scripts

branch : update-lerna-to-3.21.0

created branch time in 2 months

pull request commentOfficeDev/generator-office

Update office-addin-usage-data and other packages

Could generator-office code be updated to not require the workaround in the package? Users will need an updated generator-office one way or the other to have the fix.

TCourtneyOwen

comment created time in 2 months

push eventmicrosoft/ChakraCore-Debugger

Courtney Owen

commit sha 4b20e31df8f5c46f479908300ba09d5ea049cd18

Update to latest version of ChakraCore - Build succeeded and tests passed locally

view details

Adam Krantz

commit sha f97bb1b94411953a73c49c25ca83bd982a88ef6a

Merge pull request #90 from TCourtneyOwen/update-chakracore-version Update to latest version of ChakraCore (v1.11.19)

view details

push time in 2 months

PR merged microsoft/ChakraCore-Debugger

Reviewers
Update to latest version of ChakraCore (v1.11.19)
  • Build succeeded and tests passed locally
+15 -15

0 comment

10 changed files

TCourtneyOwen

pr closed time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Address recent drop in usage data because usagelevel set to off

 import * as path from "path";  export const usageDataJsonFilePath: string = path.join(os.homedir(), "/office-addin-usage-data.json"); export const groupName = "office-addin-usage-data";-export const instrumentationKeyForOfficeAddinCLITools = "de0d9e7c-1f46-4552-bc21-4e43e489a015";\ No newline at end of file+export const instrumentationKeyForOfficeAddinCLITools = "de0d9e7c-1f46-4552-bc21-4e43e489a015";+// Office-Addin-Scripts packages currently sending usage data+export const officeAddinScriptsPackages: string[] = [

I think a chat might help us discuss and come up with a better proposal to deal with this.

TCourtneyOwen

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Address recent drop in usage data because usagelevel set to off

 import * as path from "path";  export const usageDataJsonFilePath: string = path.join(os.homedir(), "/office-addin-usage-data.json"); export const groupName = "office-addin-usage-data";-export const instrumentationKeyForOfficeAddinCLITools = "de0d9e7c-1f46-4552-bc21-4e43e489a015";\ No newline at end of file+export const instrumentationKeyForOfficeAddinCLITools = "de0d9e7c-1f46-4552-bc21-4e43e489a015";+// Office-Addin-Scripts packages currently sending usage data+export const officeAddinScriptsPackages: string[] = [

I'm concerned about this pattern where these package names are specified. Isn't there a better way?

TCourtneyOwen

comment created time in 2 months

pull request commentOfficeDev/Office-Addin-Scripts

Address recent drop in usage data because usagelevel set to off

@TCourtneyOwen Wouldn't it be better and simpler to have the default be undefined and to not write anything when undefined so that only the true or false value about whether to prompt would cause the value to be written?

TCourtneyOwen

comment created time in 2 months

created tagOfficeDev/Office-Addin-Scripts

tagoffice-addin-debugging@3.0.28

A set of scripts and packages that are consumed in Office add-ins projects.

created time in 2 months

push eventOfficeDev/Office-Addin-Scripts

Adam Krantz

commit sha bb19226843155ec71ed7d37b617ba497f2345b4b

Publish - office-addin-debugging@3.0.28 - office-addin-dev-settings@1.8.0

view details

push time in 2 months

created tagOfficeDev/Office-Addin-Scripts

tagoffice-addin-dev-settings@1.8.0

A set of scripts and packages that are consumed in Office add-ins projects.

created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

office-addin-dev-settings: add webview command

 export async function setSourceBundleUrl(addinId: string, components: SourceBund   } } +export async function setWebView(addinId: string, webViewType: WebViewType | undefined): Promise<void> {+  const key = getDeveloperSettingsRegistryKey(addinId);+  switch (webViewType){+    case undefined:+    case WebViewType.Default:+      await registry.deleteValue(key, WebViewSelection);+      break;+    case WebViewType.IE:+    case WebViewType.Edge:+    case WebViewType.EdgeChromium:+      const webViewString: string = <string> webViewType;

I still think it would be better to define string constants for the registry values used and to use them here and in the toWebViewType function.

arttarawork

comment created time in 2 months

PR closed OfficeDev/Office-Addin-Scripts

Reviewers
dev setting to choose webview type

I still need to add tests, but I've been able to reliably flip on and off the reg key we are planning to use to activate IE debug mode.

+208 -8

2 comments

6 changed files

arttarawork

pr closed time in 2 months

pull request commentOfficeDev/Office-Addin-Scripts

dev setting to choose webview type

This pull request is outdated now.

arttarawork

comment created time in 2 months

CommitCommentEvent
CommitCommentEvent

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export async function getSourceBundleUrl(manifestPath: string) {   } } +async function getWebViewType(manifestPath: string) {+  try {+    const manifest = await readManifestFile(manifestPath);++    validateManifestId(manifest);++    const webViewString = await devSettings.getWebView(manifest.id!);

Yes, this means that the commands converts the string to an enum and back to the string, but that's OK.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export async function getSourceBundleUrl(manifestPath: string) {   } } +async function getWebViewType(manifestPath: string) {+  try {+    const manifest = await readManifestFile(manifestPath);++    validateManifestId(manifest);++    const webViewString = await devSettings.getWebView(manifest.id!);
const webViewType: WebViewType = await devSettings.getWebView(manifest.id!);
const webViewTypeString = toWebViewTypeString(webViewType);

console.log(webViewTypeString 
    ? `The web view type is set to ${webViewTypeString}.` 
     : `The web view type has not been set.`);
arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function validateManifestId(manifest: ManifestInfo) {   } } -export async function webView(manifestPath: string, webViewString?: string) {-  try {-    const manifest = await readManifestFile(manifestPath);--    validateManifestId(manifest);--    if (webViewString) {-      devSettings.setWebView(manifest.id!, parseWebViewType(webViewString));-    } else {-      const currentWebViewString = await devSettings.getWebView(manifest.id!);-      currentWebViewString ? console.log("The webViewType is set to " + currentWebViewString + ".") : -      console.log("A specific webViewType override has not been selected.");-    }--  } catch (err) {-    logErrorMessage(err);-  }+export async function webViewOverride(manifestPath: string, webViewString?: string) {+  webViewString ? setWebViewType(manifestPath, webViewString) : getWebViewType(manifestPath);

Except that you typically shouldn't use "Enum" as part of the name for the enum. You would use what the enum describes which in this case is types of webviews.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export async function getSourceBundleUrl(manifestPath: string) {   } } +async function getWebViewType(manifestPath: string) {+  try {+    const manifest = await readManifestFile(manifestPath);++    validateManifestId(manifest);++    const currentWebViewString = await devSettings.getWebView(manifest.id!);+    currentWebViewString ? console.log("The webViewType is set to " + currentWebViewString + ".") : 

The point of converting the string to the enum value is so that the function works on enum values. The conversion from the enum value to a string is so the command can show the string.

Having the exported function return the enum makes for a better "api" for using the package from code.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function validateManifestId(manifest: ManifestInfo) {   } } -export async function webView(manifestPath: string, webViewString?: string) {-  try {-    const manifest = await readManifestFile(manifestPath);--    validateManifestId(manifest);--    if (webViewString) {-      devSettings.setWebView(manifest.id!, parseWebViewType(webViewString));-    } else {-      const currentWebViewString = await devSettings.getWebView(manifest.id!);-      currentWebViewString ? console.log("The webViewType is set to " + currentWebViewString + ".") : -      console.log("A specific webViewType override has not been selected.");-    }--  } catch (err) {-    logErrorMessage(err);-  }+export async function webViewOverride(manifestPath: string, webViewString?: string) {+  webViewString ? setWebViewType(manifestPath, webViewString) : getWebViewType(manifestPath);

This looks good. You could name the parameter webViewTypeString for consistency. As I mentioned before, this function could just be named webView().

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 const UseDirectDebugger: string = "UseDirectDebugger"; const UseLiveReload: string = "UseLiveReload"; const UseProxyDebugger: string = "UseWebDebugger"; const WebViewSelection: string = "WebViewSelection";-const IE: string = "ie";-const Edge: string = "edge";-const EdgeChromium: string = "edge chromium";+const WebViewTypeString_IE: string = "ie";

This is where it would be good to make the display strings mixed case, e.g. "Edge", "IE"

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 commander commander     .command("webview <manifest-path> [web-view-type]")     .description("Allows specifying a preference for the type of web view to use when debugging. Windows only")-    .action(commands.webView)+    .action(commands.webViewOverride)

Maybe I gave poor guidance earlier but I would be OK with the function webView() being for the "webview" command. It was the exported functions that I wanted to have a better name. Hope I didn't cause confusion.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export async function getSourceBundleUrl(manifestPath: string) {   } } +async function getWebViewType(manifestPath: string) {+  try {+    const manifest = await readManifestFile(manifestPath);++    validateManifestId(manifest);++    const currentWebViewString = await devSettings.getWebView(manifest.id!);+    currentWebViewString ? console.log("The webViewType is set to " + currentWebViewString + ".") : 

You could simplify the name to just webViewString.

Why not have return the WebViewType enum. You could write a function in devSettings toWebViewTypeString(webViewType: WebViewType): string which uses the switch to return the string constant for the enum value. For Default, you can return an empty string.

Then here in the command you could use the function to convert to the display text and show it in the message.

Use ${variable} in a string form rather than using + to concatenate the string.

Make the string contants mixed case, e.g. "Edge" so they display nicer. The case shouldn't matter for the command input.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 commander     .description("Unregister the Office Add-in for development.")     .action(commands.unregister); +commander+    .command("webview <manifest-path> [web-view-type]")+    .description("Allows specifying a preference for the type of web view to use when debugging. Windows only")+    .action(commands.webView)+    .on("--help", () => {+        console.log("\nFor [web-view-type], choose one of the following values:\n");+        console.log("\t'edge' for Microsoft Edge");+        console.log("\t'ie' for Internet Explorer 11");+        console.log("\t'default' to remove any preference");+        console.log("...or leave [web-view-type] blank to return the current setting");

Suggest changing the last line to: \nOmit [web-vew-type] to see the current setting.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function validateManifestId(manifest: ManifestInfo) {     throw new Error(`The manifest file doesn't contain the id of the Office Add-in.`);   } }++export async function webView(manifestPath: string, webViewString?: string) {

While the command name is webView, we could choose a more descriptive name for the exported function. Also, we shouldn't have the console.log() statements be in the exported function. I think what would be better to is to have separate functions setWebViewType() and getWebViewType() and take the code which checks if webViewString is truthy or not and does set or get and move that to the command implementation.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 const SourceBundlePort: string = "SourceBundlePort"; const UseDirectDebugger: string = "UseDirectDebugger"; const UseLiveReload: string = "UseLiveReload"; const UseProxyDebugger: string = "UseWebDebugger";+const WebViewSelection: string = "WebViewSelection";+const IE: string = "ie";

It would help to use a common prefix for these strings, e.g. `const WebViewTypeString_IE = "ie"; const WebViewTypeString_Edge = "edge"; etc.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function parseStringCommandOption(optionValue: any): string | undefined {   return (typeof(optionValue) === "string") ? optionValue : undefined; } +export function parseWebViewType(webViewString?: string): devSettings.WebViewType | undefined {+  switch (webViewString ? webViewString.toLowerCase() : undefined) {+    case "ie":+    case "ie11":+    case "internet explorer":+    case "internetexplorer":+      return devSettings.WebViewType.IE;+    case "edge":+    case "spartan":+      return devSettings.WebViewType.Edge;+    case "edge chromium":+    case "edgechromium":+    case "anaheim":+      return devSettings.WebViewType.EdgeChromium;+    case "default":+    case "":+      return devSettings.WebViewType.Default;+    case null:+    case undefined:+      return undefined;+    default:+      throw new Error(`Please select a valid webViewType instead of '${webViewString!.toLowerCase()}'.`);

You don't need toLowercase() here as you are just showing the value they put.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 commander     .description("Unregister the Office Add-in for development.")     .action(commands.unregister); -//TODO: change the way this works to reflect changes to setWebView commander-    .command("webview <webview>")+    .command("webview <manifest-path> <webview>")     .description("Changes the webview used for addins on win32.")     .action(commands.setWebView)     .on("--help", () => {         console.log("\nValid options for 'webview <webview>':\n");         console.log("\t'edge': Sets webview to be Edge");         console.log("\t'ie': Sets webview to be Internet Explorer 11");-        console.log("\t'clear': Clears any specific webview choice");-        console.log("\t'default' or undefined: Doesn\'t make any webview changes");+        console.log("\t'clear': Clears any specific webview choice, default webview will run");     }); -//TODO: change the way this works to reflect changes to getWebView commander -    .command("get-webview")+    .command("get-webview <manifest-path>")

It would be better to combine get and set such that if a value is specified, it sets the desired value, and if not set it shows the choice. You just need to remove this command, make the [web-view-type] optional, and in the command handler, and then based on whether webViewType parameter is undefined or not, do the get or set code.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 describe("DevSettingsForAddIn", function() {         const expected = new devSettings.SourceBundleUrlComponents(undefined, undefined, undefined, undefined);         await testSetSourceBundleUrlComponents(actual, expected);       });+      it("webView can be set to Default", async function() {+        await devSettings.setWebView(addinId, devSettings.WebViewType.Default);+        assert.strictEqual(await devSettingsWindows.getWebView(addinId), "default");+      });+      it("webView can be set to IE", async function() {+        await devSettings.setWebView(addinId, devSettings.WebViewType.IE);+        assert.strictEqual(await devSettingsWindows.getWebView(addinId), "ie");+      });+      it("webView can be set to Edge", async function() {+        await devSettings.setWebView(addinId, devSettings.WebViewType.Edge);+        assert.strictEqual(await devSettingsWindows.getWebView(addinId), "edge");+      });+      it("webView can be set to Edge Chromium", async function() {+        await devSettings.setWebView(addinId, devSettings.WebViewType.EdgeChromium);+        assert.strictEqual(await devSettingsWindows.getWebView(addinId), "edge chromium");+      });+      it("webView can be cleared", async function() {

You don't need Clear. Setting default is clearing the value. Have I mentioned this enough times? :-)

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export async function setSourceBundleUrl(addinId: string, components: SourceBund   } } -export async function setWebView(addinId: string, webview: WebViewType | undefined): Promise<void> {+export async function setWebView(addinId: string, webView: WebViewType | undefined): Promise<void> {   const key = getDeveloperSettingsRegistryKey(addinId);-  switch (webview){+  switch (webView){     case undefined:     default:       break;     case WebViewType.Default:-      await registry.addStringValue(key, WebViewSelection, "default");+    case WebViewType.Clear:+      await registry.deleteValue(key, WebViewSelection);       break;     case WebViewType.IE:       await registry.addStringValue(key, WebViewSelection, "ie");

I would move the string values to constants for the names.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export async function setSourceBundleUrl(addinId: string, components: SourceBund   } } -export async function setWebView(addinId: string, webview: WebViewType | undefined): Promise<void> {+export async function setWebView(addinId: string, webView: WebViewType | undefined): Promise<void> {   const key = getDeveloperSettingsRegistryKey(addinId);-  switch (webview){+  switch (webView){     case undefined:     default:       break;     case WebViewType.Default:-      await registry.addStringValue(key, WebViewSelection, "default");+    case WebViewType.Clear:

You don't need Clear. Please remove that enum type. Default covers this.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export async function setSourceBundleUrl(addinId: string, components: SourceBund   } } -export async function setWebView(addinId: string, webview: WebViewType | undefined): Promise<void> {+export async function setWebView(addinId: string, webView: WebViewType | undefined): Promise<void> {

I would use webViewType as the variable name. It starts lowercase to distinguish from the enum WebViewType.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function parseStringCommandOption(optionValue: any): string | undefined {   return (typeof(optionValue) === "string") ? optionValue : undefined; } +export function parseWebView(webViewText?: string): devSettings.WebViewType | undefined {+  const parsedWebView = webViewText ? webViewText.toLowerCase() : undefined;+  switch (parsedWebView) {+    case "ie":+    case "ie11":+    case "internet explorer":+    case "internetexplorer":+      return devSettings.WebViewType.IE;+    case "edge":+    case "spartan":+      return devSettings.WebViewType.Edge;+    case "edge chromium":+    case "edgechromium":+    case "anaheim":+      return devSettings.WebViewType.EdgeChromium;+    case "clear":+      return devSettings.WebViewType.Clear;+    case "default":+    case "":+      return devSettings.WebViewType.Default;+    case null:+    case undefined:+      return undefined;+    default:+      throw new Error(`Please select a valid webview instead of '${parsedWebView}'. Options include (ie, edge, edge chromium, clear, default)`);

Don't list the valid options here. Just make the message simpler. It should be phrased like other similar error messages.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function parseStringCommandOption(optionValue: any): string | undefined {   return (typeof(optionValue) === "string") ? optionValue : undefined; } +export function parseWebView(webViewText?: string): devSettings.WebViewType | undefined {+  const parsedWebView = webViewText ? webViewText.toLowerCase() : undefined;+  switch (parsedWebView) {

you don't really need the variable name here. I think it would be better to move the conditional expression directly into the switch.

switch (webViewType ? webViewText.toLowercase() : undefined)

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 commander     .description("Unregister the Office Add-in for development.")     .action(commands.unregister); -//TODO: change the way this works to reflect changes to setWebView commander-    .command("webview <webview>")+    .command("webview <manifest-path> <webview>")     .description("Changes the webview used for addins on win32.")     .action(commands.setWebView)     .on("--help", () => {         console.log("\nValid options for 'webview <webview>':\n");

Suggestion for the help text:

console.log("\nFor <web-view-type>, choose one of the following values:\n");
console.log("\t'edge' for Microsoft Edge");
console.log("\t'ie' for Internet Explorer 11");
console.log("\t'default' to remove any preference");
arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function parseStringCommandOption(optionValue: any): string | undefined {   return (typeof(optionValue) === "string") ? optionValue : undefined; } +export function parseWebView(webViewText?: string): devSettings.WebViewType | undefined {

parseWebViewType would be a better name.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 function parseStringCommandOption(optionValue: any): string | undefined {   return (typeof(optionValue) === "string") ? optionValue : undefined; } +export function parseWebView(webViewText?: string): devSettings.WebViewType | undefined {+  const parsedWebView = webViewText ? webViewText.toLowerCase() : undefined;+  switch (parsedWebView) {+    case "ie":+    case "ie11":+    case "internet explorer":+    case "internetexplorer":+      return devSettings.WebViewType.IE;+    case "edge":+    case "spartan":+      return devSettings.WebViewType.Edge;+    case "edge chromium":+    case "edgechromium":+    case "anaheim":+      return devSettings.WebViewType.EdgeChromium;+    case "clear":

You don't need "clear". Specifying "default" or "" will clear the value.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 commander     .description("Unregister the Office Add-in for development.")     .action(commands.unregister); -//TODO: change the way this works to reflect changes to setWebView commander-    .command("webview <webview>")+    .command("webview <manifest-path> <webview>")

might consider changing <webview> to <web-view-type>

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 commander     .description("Unregister the Office Add-in for development.")     .action(commands.unregister); -//TODO: change the way this works to reflect changes to setWebView commander-    .command("webview <webview>")+    .command("webview <manifest-path> <webview>")     .description("Changes the webview used for addins on win32.")

Suggestion for description:
Allows specifying a preference for the type of web view to use when debugging. Applies to Windows only.

arttarawork

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 commander     .description("Unregister the Office Add-in for development.")     .action(commands.unregister); -//TODO: change the way this works to reflect changes to setWebView commander-    .command("webview <webview>")+    .command("webview <manifest-path> <webview>")     .description("Changes the webview used for addins on win32.")     .action(commands.setWebView)     .on("--help", () => {         console.log("\nValid options for 'webview <webview>':\n");         console.log("\t'edge': Sets webview to be Edge");         console.log("\t'ie': Sets webview to be Internet Explorer 11");-        console.log("\t'clear': Clears any specific webview choice");-        console.log("\t'default' or undefined: Doesn\'t make any webview changes");+        console.log("\t'clear': Clears any specific webview choice, default webview will run");

I personally don't think "clear" which is a verb is a good choice here. I think "default" is better.

arttarawork

comment created time in 2 months

pull request commentOfficeDev/generator-office

Upgrade Fabric UI

This repo is still used. The templates however are managed from separate repositories.

freerangeeggs

comment created time in 2 months

PR closed OfficeDev/generator-office

Upgrade Fabric UI

Thank you for your pull request. Please provide the following information.


  1. Do these changes impact User Experience? (e.g., how the user interacts with Yo Office and/or the files and folders the user sees in the project that Yo Office creates)

    • [x] Yes
    • [ ] No

    If Yes, briefly describe what is impacted.

Uses the current available UI Fabric, and changed references to Fabric Styling works from the start

  1. Do these changes impact documentation? (e.g., a tutorial on https://docs.microsoft.com/en-us/office/dev/add-ins/overview/office-add-ins)

    • [ ] Yes
    • [x] No

    If Yes, briefly describe what is impacted.

  2. Validation/testing performed:

  • Ensured npm i was successful
  • Built and ran
  • Styling was as expected
  1. Platforms tested:

    • [x] Windows
    • [ ] Mac
+4 -4

1 comment

3 changed files

freerangeeggs

pr closed time in 2 months

pull request commentOfficeDev/generator-office

Upgrade Fabric UI

The templates are not directly in generator-office anymore. See https://github.com/OfficeDev/Office-Addin-TaskPane for the basic template. The other Yo Office templates derive from it.

freerangeeggs

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Create install script that install dependencies for each package

   "scripts": {     "build": "lerna run build",     "dist-tags": "lerna exec --concurrency 1 --no-sort --stream npm dist-tag ls",+    "install": "lerna exec --concurrency 1 --stream -- npm install --no-fund --no-optional",

I thought about adding this here as well. install-packages to avoid overwriting npm install behavior generally.

We don't want to run this all the time. Just the one time as needed. So npm run install-packages when neccessary, and then npm install after which will do the post-install lerna bootstrap.

TCourtneyOwen

comment created time in 2 months

create barnchakrantz/Office-Addin-Scripts

branch : win10-version-check

created branch time in 2 months

pull request commentOfficeDev/Office-Addin-Scripts

Enable code to ensure Edge loopback is enabled

@TCourtneyOwen Please don't merge if the CI is failing. The failures on Windows can be mitigated manually so that we can get the CI passing.

TCourtneyOwen

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Enable code to ensure Edge loopback is enabled

 export async function startDebugging(manifestPath: string, appType: AppType, app             throw new Error("Manifest does not contain the id for the Office Add-in.");         }     -        // DISABLE FOR NOW         // enable loopback for Edge-        // if (isWindowsPlatform) {-        //     const name = isDesktopAppType ? "EdgeWebView" : "EdgeWebBrowser";-        //     await devSettings.ensureLoopbackIsEnabled(name);-        // }+        if (isWindowsPlatform && parseInt(os.release()) === 10) {

@TCourtneyOwen did you make a change here?

TCourtneyOwen

comment created time in 2 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Enable code to ensure Edge loopback is enabled

 export async function startDebugging(manifestPath: string, appType: AppType, app             throw new Error("Manifest does not contain the id for the Office Add-in.");         }     -        // DISABLE FOR NOW         // enable loopback for Edge-        // if (isWindowsPlatform) {-        //     const name = isDesktopAppType ? "EdgeWebView" : "EdgeWebBrowser";-        //     await devSettings.ensureLoopbackIsEnabled(name);-        // }+        if (isWindowsPlatform && parseInt(os.release()) === 10) {

It would be a bit more readable if add const isWindows10: boolean = isWindowsPlatform && parseInt(...); on line 199 just after the declaration of isWindowsPlatform, so that here you can just use if (isWindows10)

TCourtneyOwen

comment created time in 3 months

issue commentOfficeDev/office-js-docs-pr

quickstarts/excel-quickstart-vue certificate problem

Adding @TCourtneyOwen to the thread. @AlexJerabek, it is difficult to understand what is the issue now from this re-opened thread. It would help if you can reproduce the issue and summarize what you're seeing.

LewisPringle

comment created time in 3 months

Pull request review commentOfficeDev/Office-Addin-Scripts

Adding Webview switching to office-addin-debugging

 export enum DebuggingMethod { }  export enum WebViewType {+  Default,   IE,   Edge,-  Clear+  EdgeChromium,+  Clear,

You don't need "Clear". Setting the "Default" should clear the setting.

arttarawork

comment created time in 3 months

more