Monday, May 7, 2018

SharePoint 2013 date picker scrolls form to the top

Just recently noticed a bug in SharePoint 2013... Yeah, I know it is 2018 now LOL

The bug is simple but very annoying.
If you have a long list form, with many columns, and you have a few date columns at the bottom - beyond the scroll position - clicking any date picker will open the picker but will scroll your page to the top.

This happens when using non-IE browsers (I use chrome), and it is the result of the following code running INSIDE the picker iframe:
    function: setFocusDatepicker

Is trying to set focus to the current date element.

Now, since this code is executed in the iframe it could be tricky to fix, since we don't have any code running in that iframe, but our code runs on the current window...

But there seems to be a fix for that we can use a little (a lot actually) JavaScript trickery to manipulate the frame's code from the containing document.

We will hook up to OnIframeLoadFinish function, which is called when the iframe of the picker is ready.

Once inside, we will find the function setFocusDatepicker INSIDE the iframe.
(Note: this is only allowed since we are on the same domain as the iframe...)

Then we will override the setFocusDatepicker to keep the workspace scrollTop, call setFocusDatepicker, and then restore the workspace scrollTop.

Here is the complete code, just call it once after all scripts were loaded:


ExecuteOrDelayUntilScriptLoaded( function() { if (typeof(window.original_OnIframeLoadFinish) !== 'function') { window.original_OnIframeLoadFinish = window.OnIframeLoadFinish; window.OnIframeLoadFinish = function() { original_OnIframeLoadFinish.apply(this, arguments); window.Picker.contentWindow.original_setFocusDatepicker = window.Picker.contentWindow.setFocusDatepicker; window.Picker.contentWindow.setFocusDatepicker = function() { workspaceTop = document.getElementById('s4-workspace').scrollTop; window.Picker.contentWindow.original_setFocusDatepicker.apply(this, arguments); document.getElementById('s4-workspace').scrollTop = workspaceTop; } } } }, "datepicker.js");

Enjoy!

Monday, April 9, 2018

Upgrading SPFx React from 1.1.0 to 1.4.0 build errors

Hey guys,

I've been playing with my SPFx demo project (code here on GitHub) getting ready for my session @SPSTC when I decided perhaps its time to upgrade one of my demo web parts to SPFx version 1.4.0 while keeping the other one in 1.1.0 so that I can discuss the upgrade process.

The upgrade process is, as I stated many times, a very tedious and hard manual work - and VERY error prone and time consuming.

Here are a few notes I gathered from this upgrade that I'd like to share - join my session to get the full picture!

Following this article as my base-line: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/update-latest-packages
There are a few things that went wrong here...

React versions

If you follow this guide, it says to run npm outdated and get all packages to the latest versions. Well, that simply is bad advice since when it comes to the react packaged - you should get the same version that the Microsoft packages are using. This is not explained anywhere - you just end up with hundreds of errors in your gulp command with no clue why they are there or how to fix them. I simply went into the Microsoft packages and saw they were using these versions so I used the same:
  • "@types/react": "15.6.6"
  • "@types/react-dom": "15.5.6"
  • "react": "15.6.2"
  • "react-dom": "15.6.2"
That brought down the errors count to 1. Sounds simple? Not so much...

React createComponent error

See, in my web part demo that was built on version 1.1.0 of SPFx - the react component class was declared as:
export default class ReactWebPart extends React.Component<IReactWebPartProps, void>
In the web part class, it was used in this code:
      const element: React.ReactElement<IReactWebPartProps> = React.createElement<IReactWebPartProps>(
        ReactWebPart,
        {
          description: this.properties.description,
          userName: Utilities.GetUserName(this.context as any),
          license: licenseMessage,
          color: this.properties.color
        }
      );
which, in turn, produced this error message:
Error - typescript - src/webparts/reactWebPart/ReactWebPartWebPart.ts(27,8): error TS2345: Argument of type 'typeof ReactWebPart' is not assignable to parameter of type 'string | ComponentClass<IReactWebPartProps> | StatelessComponent<IReactWebPartProps>'.
Error - 'typescript' sub task errored after 4.49 s
 TypeScript error(s) occurred.
So, we checked the typescript version we were running, all the npm modules dependencies and versions - they all seemed to check out.
We went with our favorite way for fixing SPFx versioning issues:
We created a new sample SPFx React web part, and if that one (hopefully) compiles - we compare the two.

In our case, since this is a sample component without a lot of code - it was easier to find the difference between the two.
In the new project, the react component class is defined with one difference:
export default class ReactWebPart extends React.Component<IReactWebPartProps, {}>
See, the "void" that was sent in as the react state was changed to an empty object.

This made the error go away and now our project compiles with no problem. Yay!

I can't help but feeling SPFx tooling still has a long way to go before it will be adopted by the mass development community. It can get pretty frustrating every time you have to move computers or upgrade versions to the point that it is just scary and unpredictable.

That said - I have to admit it is brilliant, fast and fun to build on when you get it to compile. So - I'm keeping my hopes up for this platform.

I will continue to provide this feedback to the team @Microsoft, which are doing a great job at listening for feedback, but please also share your experience in the comments below, on their GitHub project  or by voting on user voice requests.

Here is a link to the GitHub with this project in case you want to see the code changes during the upgrade: https://github.com/KWizCom/SPFxDemo

Hope this helps,
Shai.
Funny thing... not 5 minutes after posting this, I went back to my demo and run gulp. Guess what? It errored out. This time showing this strange error:
[17:53:08] Error - Unknown
 Cannot find module 'typescript'
Guess what worked this time to fix this? delete node_modules folder and running npm install again...

Wednesday, March 28, 2018

Transforming SharePoint radio buttons to appear horizontal

Recently I was at SharePoint Fest DC.
While I was at KWizCom's booth, one of our customers approached me with a question: He had a list form with lots of radio buttons.
They each had just a few choices, but the form didn't look very nice since they all stretched out too long and narrow.
See, SharePoint always renders radio button choice fields vertically...

He wanted to have these choice columns render in a horizontal layout instead of the OOB vertical one. (side by side instead of under each other)

In other words, from something that looks very much like this:
Into something that looks like this:

(Due to privacy of his content, I can't share his exact form layout - but he had a few more of them spread around the form)

So, you might notice the customer was already using our forms solution and had the form render in a 2 column layout and with the column captions above the controls.

Because of that, the change he requested was very simple to implement so I was happy to do it on the spot with him, on his laptop.

It took about 2 minutes to complete, he was very impressed, but I must admit - this wasn't a very challenging request if you know your way around CSS.

All he had to do was:
1. Create a CSS file with a new class that targets the table in radio buttons choice columns
2. Change the rows of the table to display inline instead of breaking row like it usually does in HTML
2. Save the CSS file in site assets
3. Get our Forms solution to load this new CSS file and all done!

Here is the CSS needed to make this change, it should work on SP2013, SP2016 and SharePoint online in classic UI:

table[id$='RadioTable'] tr{ display: inline; }

Note: if you don't use KWizCom Forms, you will have to load the CSS some other way to the page, but this solution should still work.

Note #2: this wasn't tested on modern UI, but on classic. It might require some minor tweaking to work in modern UI, let me know in the comments if this is something you need and having trouble achieving.

Enjoy!