'Color variable behavior changes when mouse leaves focus of input box expression area

[evan_kurowski]

https://community.qlik.com/inbox?objectType=38&objectID=5335

Cross-referencing thread in main area, so .QVW demonstrating behavior can be attached.

Hello All,

Rob's analysis (thank you Rob for evaluating this) prompted me to examine again, and I think I have new information to add.

This behavior is reproducible on my end, and I've attached an app demonstrating the effect, which I'm describing as 'Color variable behavior changes when mouse leaves focus of input box expression area'

*Reloading the attached application allows the effect to be repeated

Two color variables are being created in script, and they work fine.. UNTIL they are "touched" in an input box expression area.

Then once the mouse focus leaves the input box and clicks somewhere else on the application, the variable behavior changes, and the color expressions detach. (The reason this appears so strange, is the definition of the variable itself is not altered, but obviously some other hidden property is in motion, merely by entering/exiting the edit window.  This may not be limited to just color variables, could this effect any type of variable?)

So trying to pin down the 'where' of the effect was misleading.  If a user touches the variables on desktop, the breakage is visible on desktop.  If the variables were "touched" on the server, it makes it appear as breakage originates on server.

**Addendum: ***Addendum:  Performing an A/B comparison of the .QVW project export pre/post effect is not producing any observable difference.  Performing a WinMerge diff on the pre/post .QVW triggered the following alert, but no immediately obvious change visible in the XML portions of the .QVW

[rwunderlich]

I don't think this is a bug. In the script. you are creating (indirectly)

LET Color.Blue = rgb(0,144,214);

This evaluates the rgb() expression and sets Color.Blue to the result -- a proper dual color code. So a direct reference to Color.Blue in a color chip will work because there is a color number there.

The input box displays the string value of the Dual.  When you click in the input box and then away, you are updating the variable to have string only. It is no longer Dual.

At this point the color chip must use $(Color.Blue) to cause the rgb() function to be evaluated into a color code.

What you can do is use $(Color.Blue) always in the color chip and then it will work in both cases.

Demystifying dollar sign expansion is always a favorite topic at the Master Summit BTW.

-Rob

http://masterssummit.com

http://qlikviewcookbook.com

[evan_kurowski]

Rob Wunderlich

The input box displays the string value of the Dual.  When you click in the input box and then away, you are updating the variable to have string only. It is no longer Dual.

Hello Rob,

If a variable with a singular "visible" programmatic definition can be interpreted along varying data types, and we lack granular control to direct it to any specified data type, even if this isn't considered a bug, it represents a design need.

The shift in variable data type is not observable anywhere in the project export, nor in A/B comparison of the .QVW.  This doesn't feel like demystification, just secret behavior, and suggests the proper way to detect/control variable data type shifting is to continuously try both Text() and Num() simultaneously, watching for changes (or at least knowing all the secrets).

I disagree that merely touching Input Box expressions should be allowed to make unidirectional conversion of Dual() data type variables into strings.  Expect plenty of developers and end-users inadvertently encountering this (a seemingly innocent interaction), not expecting/wanting/noticing data type shifting.

[rwunderlich]

Don't put too much stock in my terminology.  I don't fully understand the "dual" behavior of a variable.  I can see that after the eval, num(varname) returns a number.  I don't fully understand the internal mechanism, but I can demonstrate it as the difference between

=num(rgb(100,0,0))

=num('rgb(100,0,0)')

Perhaps I shouldn't have used the term Dual, as that implies a type.  It's not a type that changes, it's the value.  That's why you see no change in your diff. The prj directory does not store variable values, only variable names.

-Rob

[evan_kurowski]

Hello Rob,

Describing the variable as a Dual data type seems consistent here, as it can be observed the variable returns different representation for both the String vs. Numeric side - i.e. Text() vs. Num(). 

What appears to be consistently happening, is when expression cells of an Input Box are touched, and that cell contained a certain type of dual variable formed during scripting, when mouse focus enters & then leaves the edit box (without performing any keystrokes), these variables are "shedding" their numeric side and unidirectionally converting to string. 

(*Note: Suggesting "unidirectionally", as I'm not yet aware of syntax that restores the dual behavior while preserving identical variable attributes created during scripting)

The diff comparison was not just limited to the prj directory, but included the XML inside the .QVW as well.  The variable related <VariableDescription> tags do not change after the Dual ~> String conversion is observed.  (However, there isn't an obvious way to check for effects in the non-XML encoded areas of the .QVW)

This “shedding” behavior is not limited to just Color variables.  The following script assigned variable will also “shed” the numeric side when touched in an Input Box:

Let vDualInScript = Dual('This string was assigned a numeric value',8);
       

• DOES NOT shed numeric side when the variable expression is “touched” via the Settings ~> Variable Overview
• DOES shed numeric side when the variable expression is “touched” via Input Box
• DOES shed numeric side when the variable expression is "touched" via Settings ~> Document Properties ~> Variables
  

If we’re not describing this in bug terms, it still seems very “quirky” to have two different routes of accessing the variable edit dialog produce asymmetrical effects on the variable data types.

This issue should probably be retitled again to ‘Script generated Dual data type variables are shedding their numeric side representation, when touched in the edit expression window via Input Box”

**Addendum: 

Alternate syntax within the UI to get the Dual properties back seems possible, and in a way that does not shed the numeric side when the mouse enter/exists the exrepssion edit cell via Input Box.

=Dual(RGB(0,144,214), RGB(0,144,214))

But making this adjustment now produces observable change between the XML encapsulated in the  before/after .QVWs.
Original script generated Dual variable vColor.Blue:
<RawValue>RGB(0,144,214)</RawValue>

   

UI “restoration” of Dual variable properties for variable vColor.Blue:

<RawValue>=Dual(RGB(0,144,214), RGB(0,144,214))</RawValue>