I need to be honest. I have worked my way round those small challenges and it is not quite correct to call this a wish, but it seemed unnatural to mention this in General Discussion.
It looks like the only way to place an expression or variable value into an action property, is to declare this property as String. I can then call something like Context.TryExpandExpression(APropertyName, Context.Properties.PropertyAsString[APropertyName],…)
If my target property is Integer, like BuildNumber, I need to remember to declare it as String, otherwise my expression (for example
%BuildNumber%) disappears, even if edit box on Property Page allows to write string into it.
Almost the same thing happens with variables. The only way I found for decrementing one integer variable by another integer variable’s value, was to use a script. SetVariable action with forced integer output simply fails, telling me that ‘2-1’ is not an integer value.
This kind of behavior - when in doubt, treat everything as a string - is consistent through the whole FinalBuilder, I need to give FB team a big credit for this.
But sometimes it would be nice if integers could be declared and treated as integers…
Side note: It looks like one of the changes from 3.0 to 4.0 was that expressions in custom action properties were no longer being automatically expanded. I am not quite sure, what you were trying to achieve by this, but 3.0 behavior was sufficient for me in many cases.
Maybe an “editing type” and an “internal type” for variables and properties could be a solution? And then, InternalType=integer would mean that any expression is automatically expanded?
Maybe an “Always expand” checkbox for a property would be nice for those who only need a value from a property and not a knowledge about how this value is produced?
Hi Didzis,
Thanks for your post. FinalBuilder properties & variables are actually all stored internally as Variants.
I was a little confused about everything you said here, but I’ll try and respond to each comment:
1) You’re correct that Set Variable cannot evaluate numeric expressions at the moment. I’ll put a Set Variable (Numeric) actiono on our to do list. I envisage such an action would allow you to parse and evaluate numeric expressions inside the action.
2) You’re correct that, if using a variable in a custom action property, it needs to be declared as a String if you want to be able to set it to a variable name. In some cases you don’t want this (ie when you are using a SpinEdit box.) You’ll need to any strict type checking at the level of the action script. It helps that JScript and VBScript only use variants, so they’re pretty lax about type checking.
3) I like your idea of an “always expand” checkbox, however it’s not always that simple (for instance at design time you would not want to be automatically expanding the variable.) The other day (while coding in Action Studio) I was thinking about adding some new methods to the Context object which look like this: Context.ExpandProperty(“PropertyName”) which is shorthand for Context.ExpandExpression(Context.Properties.PropertyAsString(“PropertyName”),true). Could possible add Context.ExpandIntegerValue(“PropertyName”), as well. I’ll add this to the to-do list for a future version.
4) I’m afraid that I don’t know what your “Side Note” is referring to, because I don’t think expressions were ever automatically expanding in custom actions. One of the “older hands” may know what this is referring to, though…
Thank you for 1, 2 and 3
Regarding 4, I was just plain wrong, I am sorry for that. I just looked at my old FB3 code and I was setting property values in script code, avoiding expression expansion completely.
I was too lazy to make property pages for all my 10 custom actions back then. Now I have found out how to do most of the things in FB and reorganized VSS to better help our build process, so I only have 4 custom actions with property pages.
Hi Didzis,
Glad to see you’ve worked it out.
I agree with the general gist of your post, which is that it’s fiddly to expand lots of properties at once. One trick which I use when a package has a lot of string properties which need to be expanded is to insert a small nested function into the bottom of the action script event, which looks like this:
function ExpandProperty(Name) {
return Context.ExpandExpression(Context.Properties.PropertyAsString(Name),true);
}
This lets me write more succinct code in the body of the event, ie
var myLocalVar = ExpandProperty(“MyActionProperty”);
You could so something similar with VBScript, if that’s your preferred scripting language.
As I said, we’ll look into adding this support to the Context object directly, so you don’t need this hack.
- Angus
I am using Delphi, so I wrote a (boolean) function for each type I was going to use (string, integer and boolean). It uses TryExpandExpression method of Context to return the value into VAR parameter, setting function value to true when I succeed in converting the property value to target type.
Like this:
function TryGetBoolProperty(const APropertyName:WideString;
const Context: IFBCustomActionExecuteContext; var NewValue:Boolean; AllowEmpty:Boolean=False):Boolean;
var
TempValue:WideString;
begin
TempValue:=Context.Properties.PropertyAsString[APropertyName];
Result:=Context.TryExpandExpression(APropertyName, TempValue, not AllowEmpty, TempValue);
if not Result then
begin
Context.SendLogMessage(Format(‘Failed expanding boolean property ‘’%s’’’,[APropertyName]));
exit;
end;
Result:=TryStrToBool(TempValue, NewValue);
if not Result then
begin
Context.SendLogMessage(Format(‘Error in property ‘’%s’’’,[APropertyName]));
Context.SendLogMessage(Format(’ Failed to convert ‘’%s’’ to boolean’,[TempValue]));
end;
end;
Hi Didzis,
I see. I’m glad this worked out for you as a temporary solution.
- Angus