Is there a way to reload only the GUI level?

[datanibbler]

Hi,

I just noticed something very strange: In one of my apps, a variable - v_days_YTD (the nr. of days past this year, which should be 297 or so) returned 0.

So I deleted it and copy-pasted the code again from another app where it worked - I couldn't spot a difference, but anyway.

It still didn't work, it returned 0.

=> I had to reload the app, then suddenly it returned the correct number.

I thought up to now that variables defined on GUI-level should be updated continuously, not only when reloading the document?

Apparently, this is not so.

Is there a way then, to reload the GUI of a QlikView app without reloading the script?

Thanks a lot!

Best regards,

DataNibbler

P.S.: It just happened again - and what's even stranger: When I replace the code of a very complex IF-construction with a PICK(MATCH()) fct. - previously tested on the same app in another directory - that variable suddenly breaks - before, it returned the correct value, now it suddenly returns 0 - then I have to paste the code from another app again and reload.

What can be the reason for this?`

Oh, the variable "v_days_YTD" is:

>>> COUNT({1<%Datum = {">=$(=makedate(year(today()), 1, 1))<$(=DATE(v_today_num))" }>} Werktag)  <<<

(where "Werktag" is a binary field - returning 1 for a day from Mo-Fri, 0 for Sat and Sun, and "v_today_num" is today's numeric date)

[swuehl]

I don't know a method to 'reload' only the GUI (depart maybe from closing / reopening it).

As you said, variables should be reevaluated as needed automatically (but I am not sure if this is needed here after reload / opening, because your expression seems to be quite static).

It seems to me that copying / replacing the expression from another qvw haven't had a big effect, instead, reloading  made the difference, can you confirm that (i.e. also your original expressions work after reload)?

What might cause the expression to return zero is, when the field modifier is evaluated to an invalid value range.

So, next time you see this problem, please check your expression and all sub-expressions (dollar-sign expansions) e.g. in text boxes on the returned results, to narrow down the issue to its cause.

Could it be that your application is reloaded in another computer, using different OS standard date format that does not match your %Datum field format?

[Anonymous]

I suspect that the v_today_num is the culprit.  Is it a variable?  If yes - how it is defined?

In any case, a simpler way to get the number of days since the year start is this:

=floor(ReloadTime()) - YearStart(ReloadTime())

I'm using ReloadTime() instead of today() because in most cases this definition of "today" is more relevant.

Regards,

Michael

[Peter_Cammaert]

I encountered comparable behavior.

Imagine my script stores colors in variables like this:

Let vColor1 = (RGB(171,171,171));

After a Reload, Settings->Variables shows vColor to contain string RGB(171,171,171).

Next, an UI object is assigned a Calculated color. I can use two forms that use this variable, and both

=vColor1

as well as

=$(vColor1)

will work out just fine. Light gray is the color.

Now if I open Settings->Variables and change the value of vColor1 to RGB(128,128,128), different things will happen depending on the formula used in Calculated Color:

Again

=$(vColor1)

will work out just fine and objects change to dark gray. But

=vColor1

will turn every object that uses this form into... ORANGE!

Color changes back to dark gray across all objects AFTER a reload.

?

Peter

[Josh_Good]

To add toMichael Solomovich replay, the Today() and Now() functions can be qualified further based on what is put in the brackets.

now([ timer_mode])

Returns a timestamp of the current time from the system clock. The timer_mode may have the following values:

     0 Time at previously finished reload (not currently ongoing reload)
     1 Time at function call
     2 Time when the document was opened 

Default timer_mode is 1. The timer_mode = 1 should be used with caution, since it polls the operating system every second and hence could slow down the system.

today([timer_mode] )

Returns the current date from the system clock. The timer_mode may have the following values:

     0 Date at script run
     1 Date at function call
     2 Date when the document was opened  

Default timer_mode is 2. The timer_mode = 1 should be used with caution, since it polls the operating system every second and hence could slow down the system.

LocalTime([timezone [, ignoreDST ]])

[swuehl]

If you use SET instead LET in your variable definition in the script, do you get a consistent 'wrong' color even after reload? (I assume orange is due to your color palette, I get something different)

I believe that's the difference in your setting, creating an underlying color value when defining the variable or just a text.

When defining a text, I always use dollar sign expansion to replace variable with the actual text when the text needs to be evaluated as QV function (and not as a constant number for example), I believe there is no other way to let QV parse the expression correctly.

[swuehl]

Josh and Michael,

I do agree, there are other methods to calculate the number of working days (I would try networkdays() though, instead of simply subtracting yearstart() from today() ), but I believe, this issue is more about the changing value, not about how to calculate working days.

[Anonymous]

Stefan,

I think there are several issues here, where the central one is changing values.  We don't have a reply yet, so I still think it is about the definition of the variable(?) v_today_num.

I'm inclined to agree with you about the networkdays(), maybe this is what Friedrich Hofmann really needs, but his expression is count(), not sum(), hence it returns calendar days rather than working days.  It maybe a mistake, or maybe intentional, we can only guess at this time.

Regards,

Michael

[swuehl]

Michael,

I agree there are several issues here and several possible solutions, it's just that I am most concerned when I am reading 'Value changed' and we don't understand why yet (though I believe in almost all cases, one potentially can understand the why and when and correct for this, when trying to go deeper). I just want to focus on that point.

I also agree that the v_today_num variable is a candidate for trouble, so it would be helpful to get more details.

Would it be possible that you post this app, Friedrich?

edit: And you are right, Michael, seems like Friedrich just wants to know the number of calendar days, not working days (297) 😉

Not sure why he counts this field then (probably because it's having distinct values)...