System fields not updated and user-defined function not executed

I have a Row equation which does not fire when I expect it to. I cannot even get it to execute with the key combination shift F9. Upon investigation, I suspect that the problem is not just with row equations but with the fact that the system fields itemParent and itemGParent are not being updated when an item is moved.

The formal documentation for row equations appears at: http://www.sqlnotes.net/drupal5/index.php?q=node/128.

There is a substantial discussion of when Row equations run at: http://www.sqlnotes.net/drupal5/index.php?q=node/2070. I hope that most of what is discussed there is already in the formal documentation, but I have not checked this.

If I create an item at one point in the hierarchy of an outline, and then move that item to another point in the hierarchy of the outline: I would expect a Row equation whose parameters include fields in the grid to be re-evaluated. This does not appear to happen.

The example I show occurs in the context of a simple taxonomy (classification tree). Thus item has TLI values of app (figure 1, point 1) and biz (point 2). The field Kind has a Row equation which uses the function constructPath, itself using the function ftrim (point 3).

 

For interest, but not essential to the main point of this post, here is the code of the functions ftrim and constructPath:

 Function ftrim(InStr)
' This function is intended to strip off trailing tab characters 
' sometimes left behind by Excel in a tab-delimited file
Dim outStr, lenOutStr, ix, currChar
outStr = Trim(InStr)
ix = len(outStr)
currChar = Mid(outStr, ix, 1)
While currChar = Chr(9)
  ix = ix - 1
  currChar = Mid(outStr, ix, 1)
Wend
outStr = Left(outStr, ix)
ftrim = outStr
EndFunction
 

Function constructPath(item, itemparent, itemgparent)
' This function creates a Windows-like hierarchical "path".
' Ideally, this function would be coded recursively, but I cannot find a way to make InfoQube return the parent of a given item in code.
' As coded, it only permits a three level hierarchy, grandparent, parent and item.

Dim fullPath
If  itemparent = ""Then
  fullPath = "\\" + ftrim(item) + "\\"
Else
if    itemgparent = ""Then
        fullPath = "\\" + ftrim(itemparent) + "\\" + ftrim(item) + "\\"
else
' There is a grandparent:
        fullPath = "\\" + ftrim(itemgparent) + "\\" + ftrim(itemparent) + "\\" + ftrim(item) + "\\"
EndIf
Endif
constructPath = fullPath
EndFunction

 

The item air is at the wrong point in the classification, so I click and drag it such that it is under biz rather than app (figure 2 point 1).

 
Note that the itemParent has not been updated; it still shows as app (point 2). Note especially that kind has not changed: the Row equation has not fired ( point 3). This may very well be because itemParent has not changed – although surely it ought to have done?

Only if I press F5 refresh does item parent change; and still the Row equation is not executed. I select the Kind value \app\air\, press shift F9: no change.

The only way in which I can succeed in getting the Row equation to fire is explicitly to recalculate the whole field from the Field Properties pane ( figure 3 point 1):

This behaviour is consistent with the documentation if and only if the values for kind, which were initially created using the Row equation, are treated as though they had been explicitly entered by the user – which is not the case here.

Question one: is the behaviour described correct?

Question two: when and how are ItemParent and ItemGParent updated? Can this be influenced?

Question three: if the behaviour described above is correct, is there any simpler way of ensuring that the Row equation is executed when items are moved?

AttachmentSize
Figure 1.png197.19 KB
Figure 2.png31.62 KB
Figure 3.png11.47 KB

Re: System fields not updated and user-defined function not ...

Hi Mark. I'll let Pierre answer as he knows IQ best...
That said, everything you describe mirrors my own experience.Your problem is related to those "special fields" that are in fact queries and don't actually contain data. Those don't trigger row/column equations -- at least not for now.
 
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Re: System fields not updated and user-defined function not ...

In v0.9.26PreRel37, I've modified the Field Properties dialog to reflect that some field cannot have equations. 2 cases:
  1. Central to IQ behavior: IDs 1, 10, 21, 28, 39
  2. Because they are calculated from SQL queries of actual data: 3, 4, 5, 17, 26, 29, 30, 31, 32, 33, 34, 40, 41, 42, 43, 52
 

Re: System fields not updated and user-defined function not ...

 
hmmm...
in my DB, the item, itemHTMLtext, etc. fields have equations as it's always been allowed. Does that mean that it won't work anymore ? I rely on those equations.
Some users have been using IQ for more than 7 years and changing stuff that might significantly affect their work on the flip of a coin (meaning: without consultation) can be dangerous or very annoying... No?
 
 
[Edit : 31, 32, 33, 34 : what are those ? I can't see them.]
 
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Re: System fields not updated and user-defined function not ...

Auto-assigns are still allowed for fields 1, 10, 21, 28, 39, is this sufficient ?
 

Re: System fields not updated and user-defined function not ...

Being able to update certain fields – notably item – is essential. Again, why the change? And why can you continue to allow auto-assign while not permitting row and column equations?
 
Mark GREGORY, Redon, France - GMT +1/+2; EST +6

Re: System fields not updated and user-defined function not ...

Pierre_Admin wrote:
Auto-assigns are still allowed for fields 1, 10, 21, 28, 39, is this sufficient ?
 
 
Thanks!
Yes, that would be enough. Speaking only my own usage, of course.
 
I also saw Mark's post. I agree about the beta status of IQ and the freedom the developer is allowed, etc. And everybody knows (I hope!) how much I think highly of IQ and you. That said, I also think it's important to be super careful with changes that can impact how user work as IQ has been in beta state for so long that although it's still "beta", in many ways it's not. Changes like that could ruin a day of work, or more.
 
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Re: System fields not updated and user-defined function not ...

Certain specified fields "cannot have equations": if you mean, "cannot be updated" - that makes some sense; "cannot be used in equations": then please replace or supplement them with fields that give equivalent data...
 
This access to system data is a significant strength of InfoQube. If you remove it, it make my planned use of IQ difficult or perhaps impossible. Please clarify what will change and why. I appreciate that we are making free use of beta software, and that does (in my opinion) leave you at liberty to change things before release 1.0. Thereafter, you have to maintain some high degree of reverse compatibility. The current system documentation actually includes specific reference to underlying data and queries. That requires review or elimination before version 1.0 if you intend further changes.

NB: I cannot see fields 31, 32, 33, 34 either.

 
Mark GREGORY, Redon, France - GMT +1/+2; EST +6

Re: System fields not updated and user-defined function not ...

No need to worry.
I'm just trying to make the UI clearer. If a field does not trigger auto-assigns, then there is no point in allowing users to enter them.
See my point ?
We'll adjust to whatever makes sense.
 
(for the record, the row and column equations haven't been allowed on the item field for a long long time)
(31-34 are systems fields representing all text, all numbers, etc)
 
 

Re: System fields not updated and user-defined function not ...

Pierre_Admin wrote:
No need to worry.
I'm just trying to make the UI clearer. If a field does not trigger auto-assigns, then there is no point in allowing users to enter them.
See my point ?
We'll adjust to whatever makes sense.
 
(for the record, the row and column equations haven't been allowed on the item field for a long long time)
(31-34 are systems fields representing all text, all numbers, etc)
 
 
I see.
 
Examples
 
what of I do in the itemHTMLText field autoassign:
 
AM:Icon_Statut=AddKeyword(Icon_Statut, "<img>doc</img>") |

AM:item=removekeyword(item,URLlink) |

E:Icon_Statut=RemoveKeyword(Icon_Statut, "<img>doc</img>") | 

E:item=addkeyword(item,URLlink)
 
 
The item field can trigger a dialog:
 
A:wikitag=myInputDialog(wikitag, "W I K I T A G ?" & vbcrlf & vbcrlf & "CONTENU ACTUEL  =  " & WikiTag , 5, 4, null,null,null,null, 3,"","")
 
 
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.