Is it possible to use the control index value in the control propery box to carry a value that is unique to that control even if the control is NOT part of a control array? Essentially this could allow numbering the controls at design time with a user defined value that is available at each event.
I managed to test this but I am outside of what was intended.
Normally FF designer will reset the value to zero unless it is in a real control array. With a little fiddling I made a non zero value stick with this trick:
Created a dummy label with the same name as the TextBox, made the label item zero in the control array by adjusting the tab order, adjusted the control array index in the text box (now 1) to 4. Deleted the label control. The TextBox control array number (now 4) did not change.
I compiled the program and the standard events do pass this value (4) I set in the property box at design time of the TextBox that is now NOT part of a control array.
I know this is un-intended use of control array index values but it is a design time way to get a user defined value into a control.
I suppose this is a "feature request" to allow this to be set to a non zero value even if the control is not part of a control array. Can this be put in the upcomming update? Will it create other internal FF issues?
Thanks.
I won't be messing with the ControlIndex property... there are just too many internal things that depend on it and I would fear that I would break a lot of code or introduce many subtle bugs.
Having said that, I do plan on implementing a new property for all controls called "Tag". If you come from a VB background then you know what that property does. It allows you to associate any type of text to a control at design and/or runtime.
Paul,
I was pretty sure "hitch hiking" on the control array stuff would not be 100% safe.
Now for the next question (envision "drooling and panting" as we all wait for new features) ...
Will the Tags be in the pending update and when will it "hit the street"? I am just thinking ahead and may have to do a workaround that this would solve.
I know this stuff always boils down to having any two on this list of three:
1) Fast
2) High Quality
3) Low Cost
Thanks
I have most of the code for Tags ready to go. It is just the matter of pulling it together and documenting it. I need to finish the TabControl Child Form auto-sizing first, then maybe I can squeeze in the new Tag property.
Other than that, I won't be adding any new features because I don't want to fall victim to feature creep before the update.
The Tag Property has now been implemented. Pretty easy to do actually. Since I modified FireFly's internal code for version 2.00, it is now much easier to add new properties for Controls and Forms.
Tags can be set for the Controls and Forms via the PropertyList. In code, you can set and retrieve the text values via two new FireFly Functions:
FF_Control_SetTag
FF_Control_GetTag
In my initial tests, everything seems to be working perfectly.
Paul,
Once again you come through for the customer. :D
Tags will create a great way to connect design time info and other things to the runtime environment.
It is very nice when the customer can have such a direct connection to the provider of solutions.
Thanks.