autoNumeric + Vue.js 2.0 : autoNumeric does not see value updates made via Vue

[AlexandreBonneau]

I'm having trouble making autoNumeric work well with Vue.js 2.0.

Everything looks like it's working (even pasting!), but with one small caveat ; having two inputs,

• either they share the same v-model (the javascript variable that Vue databind to the html element, which mean that when you change the data in one input, all the other elements sharing the same v-model sees their values updated accordingly),
• or when one input value change, Vue updates the second input value accordingly

...whenever you input a number in the first input, both inputs shows the updated value, but, if you focus on the second input, autoNumeric reverts the updated value to the old one it somehow 'stored' at one point.

It seems Vue.js updates the input value, but autoNumeric does not see that change happening, hence it somehow keeps the previous value and shows it on focus.

cf. the codepen where you can see that happening.

Would you see how to fix that?
Does autoNumeric store the input value that gets displayed on focus?
Is there a way or a function to update that value when modifying the input value via javascript, and not via a normal user input?

[BobKnothe]

Alexandre,

Is vue.js updating the second input with .val() method? If so that would cause the issue you are having.

In version 2.0 the "set" method is required to update the input and rawValue which is stored on jquery data. On focus autoNumeric checks the rawValue and compares that to the input value and if their is a difference the rawValue is used. This was implemented to deal with ASP.net postback.

Bob

[AlexandreBonneau]

If I understand 'asp.net's postback' right, it's like Angular 1 which always kept a 'view' value that is shown on the web page, and a 'real' value which it kept up-to-date by the engine, right?

Well, wouldn't it be a good goal to try to keep autoNumeric as much framework/technology agnostic as possible?
I mean, asp.net is rapidly being phased out by Node.js and other technologies according to the trend watchers, so I see no point is supporting a special behavior by default just for this technology, at the cost of more widespread other paradigms (ie. the databinding-oriented frameworks).

So, this behavior poses problem with very basic and common thing like updating an input by setting its value directly.
I can understand the need to use autoNumeric('set', newValue) to make autoNumeric aware of the change when you want to update a specific-known-before-use input, but it gets complicated fast when you just update an input somewhere, and need to take extra care that every inputs dependent of the value of that input gets updated as well.
This is a very common use case as soon as you use components or one of the most used frameworks that allows data-binding.

Would it be possible, specially since asp.net is not as widely used as vanilla JS/Jquery/Vue.js/Angular/etc. to either :

• add an option when initializing the input to prevent the asp.net centered behavior (ie jQueryElement.autoNumeric('init', autoNumericOptions, useSpecialForAspDotNet = true);), or even better
• as 2.0 is still in beta, make a breaking change now, so by default it does not behave like that, but needs asp.net users to specify an option to mod the behavior of autoNumeric (like jQueryElement.autoNumeric('init', autoNumericOptions, useSpecialForAspDotNet = false);) ?

This change would allow all framework users to just continue using data-binded inputs without having to deal with multiple (and borderline impossible to forecast) dependencies between inputs.

[AlexandreBonneau]

Ok, I just tested the previous codepen by using v1.9.46, and indeed it works as intended (which is great and simple!).

Would it be possible to either revert this back and put an option for asp.net users, or add an option for the rest of us to get that behavior back?

[BobKnothe]

I like your idea of having an option that is ASP.net specific.

Modifying the anDefault that checks the rawValue versus the input value seems logical or adding a new option is also an alternative.

Will keep you informed.

[BobKnothe]

Had some time to think about this.

what happens on post back is the original default value is overwritten so there is no way the autoNumeric could detect if the page was loading for the first time hence the "anDefault" option was added.

The "rawValue" was created to have a number readily available so the input would not need to be stripped.

Most developers are not going to format a value the populate the inputs with the .val(). The "set" method makes it easy - IMHO.

[AlexandreBonneau]

I'm not sure to follow your explanation about post back and initial page loading.

I understand that autoNumeric keeps a rawValue around in order to be able to speed things up in some cases. I also agree that most developer would just use either init on an input and expect its current value to get formatted, or just use set to achieve the same result when updating an input.

On the other hand, I don't see how that affect the fact that on focus, autoNumeric should by default, in my opinion, just use the input value over the rawValue it kept.
If an input value has changed, it means the user has changed it (either directly, or by modifying it via another linked input/action). The user actions should be considered as the source of truth here.

Do you still plan to allow the deactivation of the asp.net specific behavior, one way or another?

[BobKnothe]

Alexandre,

I am enjoying our conversation - it's always nice to get different and new views and ideas.

On page load autoNumeric compares the default value with the actual value of the input. If they are the same autoNumeric will format the input value. What happens with ASP.Net page is on postback the page is re-rendered changing the default value to that of the input value so autoNumeric attempts to format an value that's already formatted causing errors.

// user enters "1234.56" => "1,234.56" with default settings
// during post-back the input is re-rendered and is now showing the new default value.

I created the option "anDefault" that should be set to the same value as the default value and will retain the same value on postback.

Concerning the rawValue - I see you point with the possible exceptions:

• If the input value is overwritten with the .val() method is it the developers responsibility to ensure that the value is properly formatted not to create errors?
• With the "eDec" option and soon to be "aScale" option has two different view states "focus" & "focusout". The extended views are stored in "rawValue".

If I change the code to function as you suggest do I make exceptions for the above two options?

And if a developer can handle these exceptions then why can't they just use the "set" method? for updating the input?

Just playing the devils advocate.

Look forward to you reply

Bob

[rhyek]

For anyone that might be looking to use autoNumeric with Vue.js, I made a component that solves a few minor quirks I had to deal with. No need to modify autoNumeric. You can check it out here.

It does require autoNumeric 2.0 to work.

[BobKnothe]

Carlos.

Thank you for your contribution - much appreciated.

Bob

[BobKnothe]

To all,

I have no problem with modifying autoNumeric.

Eliminating a few lines of code on v 2.0 will fix the Vue.js issue on most most options but would create issue with "e.Dec" and the new "aScale" options that have multiple view states that rely on the "rawValue" option.

IMHO - ultimately it boils down to how easy it is to use the .val() versus autoNumeric "set" method.

So I ask that for your suggestions and options.

Bob

[rhyek]

Honestly, looking at @AlexandreBonneau's example, it seems to work ok, but it's overly complicated for something that should be rather simple to implement. I think it's very common for people wanting to use a standalone (or jQuery dependent) library with a modern JS framework to make a wrapper library that takes care of the small incompatibilities that are pretty much always present. autoNumeric should be no exception in this regard.

My component is pretty much done, pending issue #251 and I couldn't really ask for more.

[AlexandreBonneau]

Hello guys, I'm glad to see some more activity to make the great autoNumeric plugin even better!

Let me answer you both.

@BobKnothe :
Bob, when you say :

"If the input value is overwritten with the .val() method is it the developers responsibility to ensure that the value is properly formatted not to create errors?"

Yes if the developer change one single and isolated input.
But if there are multiple inputs that depends on each other, then it starts to be very hard to be able to update each and every one of those inputs manually (imagine a small accountability table (Excel-like if you will), then changing one input value would need you to manually search all the dependencies to update them ; this can get really hard, if even possible).
Also, trying to respect the 'Separation of concerns' principle, I'd say autoNumeric should be responsible for all things that is formatting/unformatting, as transparently as possible. If an input value is changed, no matter where the change comes from, autoNumeric should in my opinion take care of that change accordingly.
That way if tomorrow the developer wants to drop the use of autoNumeric for any reason (like using his code for another View (MVC-style)), he would not need to change his Controller.

"With the 'eDec' option and soon to be 'aScale' option has two different view states "focus" & "focusout". The extended views are stored in "rawValue"."

Not having seen any documentation about those, I'm not sure exactly how that works with our problem.

"If I change the code to function as you suggest do I make exceptions for the above two options?"

I cannot say anything about the second sentence talking about 'eDec' and 'aScale'.
Let's try to go back to the main issue here ; you observed a problem for users using asp.net. You fixed it (yay for them!), but not only for the relatively small asp.net users, but for everybody else (which is the majority). Now we discoreved that this 'fix' has some pretty big side effect on data-binding frameworks.
So it seems to me that the 1.9.46 behavior should be the default, and that you could make an exception for asp.net users.

"And if a developer can handle these exceptions then why can't they just use the "set" method? for updating the input?"

The developer unfortunately cannot easily manage the first exception you talk about when there are multiple dependent inputs (if its even possible without a lot of additional complex code).

"Eliminating a few lines of code on v 2.0 will fix the Vue.js issue on most most options but would create issue with "e.Dec" and the new "aScale" options that have multiple view states that rely on the "rawValue" option."

Oh, I'm sorry to hear that :/

"IMHO - ultimately it boils down to how easy it is to use the .val() versus autoNumeric "set" method."

Well, as I have written above, you can not manually 'set' all the dependent inputs easily unfortunately :(
That's a bummer, and since I do not know what 'eDec' and 'aScale' do, nor precisely how autoNumeric internals works, I won't be of much help.
I'm not sure what to tell you about that...

@rhyek :

"looking at @AlexandreBonneau's example, it seems to work ok"

Yes, but only when using v1.9.46. v2 breaks the databinding feature of Vue.js :(

That said, your component is great and close to parity with my directive, but I think its too focused and that it lacks some important features.

First, as you mentioned, it does not support pasting ; if you paste a number in the input, the v-model does not get updated.
Pasting on the other hand works well with my directive.
(By the way, supporting all the correct pasting scenarios is what makes my directive overly complicated (it takes 26 lines out of 64 just for that, cf. ).

Also some minor notes I could add ;

• The component code uses property names like rawValue (which can change in the future), instead of using the input.autoNumeric('get') method designed for that.
• It also uses jQuery declaration for event listeners. I'd say since you are already using Vue.js, why not add @focus and @input in your template to :
  1. make it more semantically clear, and
  2. allow pre-compilation of the components when using Webpack. When declaring jQuery event listeners in mounted(), you miss some big performance improvements there.

Secondly, and more importantly, my main grip is about using a component to manage autoNumeric.
Using a component means that you force the user to use that input with its default limited behavior (And what about other DOM elements like <p>, <code>, <li>, etc.?).
Using a directive, you can easily add the 'autoNumeric' functionality to any element, specially one which has already other directives modifying its behavior (think "execute an action on blur if the value has changed", "select all on Esc if the value hasn't changed, otherwise set back the oldValue saved when the input got the focus", "update another input somewhere else when changing its value (and vice versa)", etc., etc., many real-life use cases).

What I like about your component though, is that the v-model always contains the unformatted value.
(Note : it should be typecast as a Number instead of a String by the way).

tl;dr :

• A component is not the best way to add the autoNumeric functionality to an element, a directive is.
• A directive is more versatile, and has less code lines than a component.
• I think an option should be added to the init function so that the asp.net specific code could stay specific only for asp.net users.
• Although it seems that reverting back to 1.9.46 behavior as some side effect on newly developed code, I really think this should be done, but it's ultimately your call Bob (let's hope you/we can find a solution that solves all this ;))

[rhyek]

@AlexandreBonneau, I appreciate the code review. Some clarifications, though:

First, as you mentioned, it does not support pasting ; if you paste a number in the input, the v-model does not get updated.

It does get updated. You can clearly see it in action on the fiddle I linked earlier.

The component code uses property names like rawValue (which can change in the future), instead of using the input.autoNumeric('get') method designed for that.

Good catch.

It also uses jQuery declaration for event listeners. I'd say since you are already using Vue.js, why not add @Focus and @input

We're already using jQuery to initialize the input in the mounted lifecycle hook, I'd personally rather keep all configuration of the element in one place.

allow pre-compilation of the components when using Webpack. When declaring jQuery event listeners in mounted(), you miss some big performance improvements there.

I hadn't considered this, but you still have to initialize the element in the mounted hook, so I think moving the attachment of the event listeners to the template would yield negligible performance increase.

Using a component means that you force the user to use that input with its default limited behavior

What do you mean by limited behavior? If you mean adding other html attributes you can already do that, eg: <autonumeric style="color:red;" placeholder="Amount" v-model="value" :options="{mDec: 3}"/> will work.

(And what about other DOM elements like

, ,

, etc?).

I've used the autoNumeric plugin for years and have never had to use it on elements other than input. For other elements, you're better off just using some other formatting library along with filters, IMO, e.g: {{ numberProperty | format('someOptions') }}.

If you really want to use arbitrary elements, you could always just use a render function instead of a template and specify a tagName, eg: <autonumeric tagName="span" style="color:red;" v-model="value" :options="{mDec: 3}"/>. I've updated my fiddle to show how to do that.

BTW: Your image shows an old version. I can see what you meant about "limited behavior" since I had placeholder in props, but that isn't necessary. Also, your codepen shows your directive having around 70 lines of code vs my ~50 :).

[AlexandreBonneau]

@rhyek

It does get updated. You can clearly see it in action on the fiddle I linked earlier.

Sorry but it does not. Take a look at what's really going on using vue-devtools.

I'd personally rather keep all configuration of the element in one place.

This goes against the MVVM pattern that Vue.js follows, but I guess you can do whatever you want :)

so I think moving the attachment of the event listeners to the template would yield negligible performance increase

I do not have time to create a performance test, but by reading the doc thoroughly, it appears it does, specially if you managed multiple autoNumeric elements.
Also, I'm not sure about the impact of not declaring the removing of those jQuery-declared event listeners ; it might lead to memory leaks. To be confirmed.

What do you mean by limited behavior?

Well, I think I explained it in the previous post. If you only plan to have a basic autoNumeric element, then I guess a component would do, but if you want to have the flexibility to add more behaviors (not "html attributes"), a directive is the way to go.

I've used the autoNumeric plugin for years and have never had to use it on elements other than input.

Your personal experience is yours, and yours only. I'm pretty sure that if autoNumeric allows the use on 'b', 'caption', 'cite', 'code', 'dd', 'del', 'div', 'dfn', 'dt', 'em', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'ins', 'kdb', 'label', 'li', 'output', 'p', 'q', 's', 'sample', 'span', 'strong', 'td', 'th', 'u' and 'var' elements, it's because some other users needs that. I know I'm big fan of contenteditable. Why limit yourself to only one element?

you're better off just using some other formatting library along with filters

The same way I'm not a fan that autoNumeric depends on jQuery, I fail to see why you would need an additional formatting library while you already has autoNumeric?!
An additional formatting library means more loading times, and more formatting configuration to manage..

I like the render() function, even though if I were using a component, I'd prefer using a classic template which are usually easier to read and edit.

Also, your codepen shows your directive having around 70 lines of code vs my ~50 :).

Yes, the codepen you are refering to includes the code that manage all paste cases, yours doesn't. On the screenshot and to compare apples with apples, I removed the code that manage the paste events to get the same limited scope as your component.

[rhyek]

@AlexandreBonneau, like I mentioned earlier: You are using code from an old version of that fiddle. If you check again you will see a number of changes. v-model does get updated on paste.

I will unsubscribe from this thread now since it's getting kind of annoying. Hopefully someone finds the component useful.

[rhyek]

Just a couple of things:

I do not have time to create a performance test, but by reading the doc thoroughly, it appears it does, specially if you managed multiple autoNumeric elements.

This seems interesting to me. Can you provide a link to the docs where they mention this? I can't find anything and I just can't imagine how moving the attachments to the template provides anything other than a variation in aesthetics. You're not skipping any work during page render doing that.

Well, I think I explained it in the previous post. If you only plan to have a basic autoNumeric element, then I guess a component would do, but if you want to have the flexibility to add more behaviors (not "html attributes"), a directive is the way to go.

Can you explain exactly what you mean by "more behaviors"? In your previous comment you mentioned:

Using a directive, you can easily add the 'autoNumeric' functionality to any element, specially one which has already other directives modifying its behavior (think "execute an action on blur if the value has changed", "select all on Esc if the value hasn't changed, otherwise set back the oldValue saved when the input got the focus", "update another input somewhere else when changing its value (and vice versa)", etc., etc., many real-life use cases).

You do realize you can treat a component like any other html element, yes? Anything you can do with a <span/> you can do with a component. Your examples, although contrived, are completely doable with components. The last one specifically ("update another input somewhere else when changing its value (and vice versa)") is something you're already trying to solve with v-model!!

Example using the updated fiddle:

<autonumeric
  tagName="span" <--- choose your tagName or skip to use an input!
  style="color:red;" <--- native html style attribute
  v-model="value"
  :options="{mDec: 2}"
  onclick="alert('you clicked me!');"/> <--- native html event attribute 

Anyways, the Vue.js docs clearly state:

Note that in Vue 2.0, the primary form of code reuse and abstraction is components - however there may be cases where you just need some low-level DOM access on plain elements.

I don't think you can justify the use of directives for this case at all, but it is up to the developer in any case. IMO, autoNumeric is fine (pending issue #251). I definitely don't think it is necessary to remove or hinder new functionality in version 2.0 just to get it working with Vue.

[rhyek]

@AlexandreBonneau, also, I don't understand how your directive is meant to help people who want to format a <span> or <p>, for example. Looking at your code, it only works with inputs!

If you read the section for v-model in the docs:

Limited to:

<textarea> components On the other hand, my component can let you use arbitrary tags.

[BobKnothe]

@AlexandreBonneau & @rhyek,

Gentleman - here is a quick demo of the "e.Dec" option http://codepen.io/RJ_Knothe/pen/mOVpQP that demos the extended decimal places. When the input does not have focus the extended decimal places is stored in "rawValue".

So if the developer uses .val() to update the input the the problem is created. on focusin.

I can change "aN" so that a developer can overwrite the input value using .val() and this would work on regular "aN" inputs. But "eDec" and "aScale" both require the use of rawValue.

Is it simply telling the developer to use only the "set" method on there two inputs?

Bob

[BobKnothe]

On the codepen sample try focusin and focusout so you can see the behavior

[rhyek]

@BobKnothe:

I personally have no issue using .autoNumeric('set', value) and I think it's the right approach when programmatically setting a new value. It seems to me that if I as a user want to be sure proper validation is processed I should use the plugin's API directly to make any updates.

It's like setter properties in other languages. If you have something like:

class Dog {
  private int age;
  public int Age {
    get { return age; }
    set {
      if (value > 20) {
        throw new Exception("Woah! Dogs don't live that long!!");
      }
      age = value;
    }
  }
}

You wouldn't directly set age (and in this case you couldn't since the property is private and rightfully so) if you want validation to happen.

Also, when using js frameworks with databinding, you usually want to work with input events so changes are handled immediately. change, focusout, etc aren't really preferred.

In any case, could you read what I posted on issue #251? Thank you!

[BobKnothe]

@AlexandreBonneau,

I made a mod for the Vue.js issue that IMHO is a good compromise

Can you test and close the issue if you are satisfied

Bob

[rhyek]

@AlexandreBonneau, btw, with the latest 2.0 commit, you don't need your keyup and paste event handlers in your directive. You could just do:

function onInput() {
  updateVModel();
}
el.addEventListener("input", onInput, false);

Hope it helps.

[AlexandreBonneau]

Guys, you are awesome :)

I just had one holiday day, and when I come back, everything is working again with 2.0, nice! :D

So I'm not sure it's needed that I answer your previous posts, since it seems from what I just read and saw that you managed to figure out a way to make both our methods (directives and components) work.
This is very good!

Quickly ;

• I would prefer using @input instead of creating the event listeners with jQuery in mounted(), at least for letting Vue manage how and when to destroy them. I cannot find back where I read that declaring the events in the templates would lead to performance improvement due to pre-compilation, compared to using the mounted() function.
• The component way is enticing indeed, for its simplicity, but then, if a component is the default way to go, what happens is that you end up with a component for autoNumeric inputs, another for cancellable, another for callFunctionOnBlurIfChanged, etc. Then you cannot really 'mix' those components. That's why I'll prefer to use a directive for low-level behaviors like declaring an autoNumeric inputs, because I plan to have different sets of behaviors for different inputs. YMMV though.
• Indeed my directive fails to manage contenteditable enabled tags like <p>, I'll have to work on that.
• The new 'eDec' options looks great. I'm sure I'll find a use for it very soon!
• I just tried to comment onKeyup, but that breaks my directive (I see no 'input' events there).
• Also, removing 'onPaste' and relying on the autoNumeric event handlers leads to this error message "ReferenceError: assignment to undeclared variable suffix. - line 1646:34" (cf. this codepen)

Anyhow, thank you again for your work and inputs on that matter.
I'll close this issue since it fixes the problem my initial codepen had.

[rhyek]

• I just tried to comment onKeyup, but that breaks my directive (I see no 'input' events there).
• Also, removing 'onPaste' and relying on the autoNumeric event handlers leads to this error message "ReferenceError: assignment to undeclared variable suffix. - line 1646:34" (cf. this codepen)

Indeed. I think @BobKnothe made a couple formatting changes to the code that might've changed something. I have a new pull request (#257) that reintroduces the fix, plus a couple others.

[rhyek]

@AlexandreBonneau, I have created an issue about the behavior you're seeing. #259

[rhyek]

@AlexandreBonneau, the changes have been merged with this commit. Could you try again, please?

[AlexandreBonneau]

Well, this codepen is using the rawgit link so it should use the last commited version for 2.0, but the input event is still not caught, and when I paste a number with ctrl+v or with the middle mouse button, I do not see any error message like before, but it does nothing (it seems the entire paste event is dropped).

Well, in fact it does nothing when I try to paste in a input defined like that :

<input type="text" v-cdz-numeric v-model="a">
<input type="text" v-cdz-numeric="{ aPad: false }" v-model="b">
<input type="text" v-cdz-numeric="{ aSep: '.', aDec: ',', altDec: '.', aSign: '', pSign: 's', mRound: 'U' }" v-model="c">

while the paste works as intended when used on inputs defined like that :

<input type="text" v-cdz-numeric="{aSep: '', aDec: '.', altDec: ',', aSign: '', pSign: 's', mRound: 'U', vMin: '-9999999999.99', vMax: '9999999999.99', aPad: false}" v-model="years">
<input type="text" v-cdz-numeric="{aSep: '', aDec: '.', altDec: ',', aSign: '', pSign: 's', mRound: 'U', vMin: '0', vMax: '9999999999', aPad: false}" v-model="months">

I'm not entirely sure why it behave like this.

Note : back in the days when I used Angular 1, I stumbled upon the exact same problem where autoNumeric used alone would behave correctly (sending input and change events when needed), but as soon as you used autoNumeric with Angular (or now Vue.js for that matter), the input and change events never ever got to Angular (cf. the old codepen).

[AlexandreBonneau]

By the way, I'm closing this issue since the commit from Bob solved the 'autoNumeric 2 + value update made by Vue' problem.

[rhyek]

@AlexandreBonneau, hm. Rawgit caches files, btw. Using the development link in theory will update the file minutes after a new change, but who knows.

I've created a codepen using the latest file and everything's working as intended. As you can see, I'm only using the input event.

Anyways, good luck.

[kouts]

I had a similar issue, please check #217.
There should be a callback available when autoNumeric updates the value so that we could "inform" our MVVM library (in my case Ractive.js) that the value changed and update the Model accordingly.
I solved this by "hacking" autoNumeric and adding an "afterConvert" callback.

I tried autoNumeric v2.0 BETA with @rhyek codepen (transform it into an Ractive decorator) but it still does
not work when there are multiple inputs that share the same keypath.

Is there any change an "afterConvert" callback to be implemented in the autoNumeric core?

[rhyek]

@kouts, can I see your code?

[kouts]

Here is the fiddle using the "modified" autoNumeric version: http://jsfiddle.net/ufwzyh9c/1/

[rhyek]

@kouts, I'll check it out later today. Thanks.

[rhyek]

@kouts, can you try my codepen out? It's pointing to my fork which I updated just now. There was a bug when having aDec different from a period. Notice I've eliminated your callback and am using the input event.

Let me know if it works for you so I can post a pull request. Thanks.

@AlexandreBonneau this should solve your issue as well.

The link to my file is https://rawgit.com/rhyek/autoNumeric/master/autoNumeric-2.0/autoNumeric-2.0-BETA.js

[kouts]

Thanks @rhyek I tested it and I confirm your fork works with latest Ractive (0.8.4).

[rhyek]

@kouts, great! Good to hear.

[rhyek]

Posted pull request #260.

[kouts]

@rhyek I'm sorry but the second input does not update the first one in your codepen, this only works for the first input. Maybe this is an Ractive problem though?

[kouts]

@rhyek can you post a similar example using autoNumeric as Vue's custom directive (which is similar to Ractive's decorator)?
Thanks.

[rhyek]

@kouts, this is the closest I could get it to my component's functionality. It's kind of annoying because if you type in the middle of an existing number the caret is moved to the right. This is something I can easily avoid using a component. But there's your example. It works. I would have to assume it's a Ractive issue since even typing in the second input doesn't work.

[kouts]

Ok @rhyek thanks for your help.

[rhyek]

@kouts no problem. If you ever figure out what the issue is exactly I'd like to hear about it.