Page 1 of 1
Design philosophy of a Custom Control.
Posted: Tue May 21, 2019 9:27 am
by Simon Knight
I recognise that this is risky post as I'm asking for opinions but here goes......
I am in the process of completing a custom control that displays a list of thumbnail images. I created it with a specific task in mind but think it may be useful in other projects. Others may also find it useful but I want to ensure that it complies with the accepted norms of Livecode Custom Controls before I am brave enough to offer it up for inspection.
My custom control is named PhotoViewer it displays a list of sub groups that I have named polaroids :
As I hope you can see each polaroid is a group comprising an image and some fields. At present all the code that is required is stored in two behavior buttons that are placed on a sub-stack named after the control e.g. stack "photoviewerBehaviors". I adopted this structure based on a talk that Ken Ray gave back in 2011 where he recommends keeping the code of the custom control away from any code that the user might want to add. Is this still a reasonable approach?
The alternative is to place the code inside the two group scripts which would mean that the code in the polaroid is duplicated for every polaroid created. Doing it this way would mean that Photoviewer is self contained but I am concerned that the duplication of the code that each polaroid uses may cause problems when large numbers of polaroids are created.
Your thoughts are welcome.
P.S. has anyone a handle on how groups really function. I found populating a group using code a bit of a nightmare and the documentation pretty poor i.e. what are the interactions between BoundingRect, ClipsToRect and LockLoc?
best wishes
Simon
Re: Design philosophy of a Custom Control.
Posted: Tue May 21, 2019 11:32 am
by bogs
I recognize that this is risky post as I'm asking for opinions but here goes......
There is no risk at all, I'm sure you'll get a few!
I adopted this structure based on a talk that Ken Ray gave back in 2011 where he recommends keeping the code of the custom control away from any code that the user might want to add. Is this still a reasonable approach?
I think it is, but ...
The alternative is to place the code inside the two group scripts which would mean that the code in the polaroid is duplicated for every polaroid created.
I'm not sure that is the only alternative. Setting the code up as a library with the groups, for instance, might be an alternative.
For how groups really function, I'll pass for someone that actually knows what they are talking about
Re: Design philosophy of a Custom Control.
Posted: Tue May 21, 2019 2:47 pm
by FourthWorld
Before diving in your questions, which are useful for a great many things, here this particular control looks like exactly the sort of thing the DataGrid was designed to handle. Why not use the existing custom control?
Re: Design philosophy of a Custom Control.
Posted: Tue May 21, 2019 5:21 pm
by Simon Knight
Setting the code up as a library with the groups, for instance, might be an alternative.
I have no idea about libraries but will have a search of the documents.
this particular control looks like exactly the sort of thing the DataGrid was designed to handle. Why not use the existing custom control?
Because I have used a datagrid in the past and found them to be complex and fragile. By complex I mean that I have to refer to both the manual and my own notes to do anything more complex than set the dgText.
I could live with the complexity but the fragility means that projects that I have used them in often suffer from silent failures with messages getting lost, no error messages posted and an inability to trace through the code. Often my code is the root cause of the problem but it is often very difficult to identify the source of the error, meaning I waste time rolling back code hoping to stumble on the cause.
So a little while ago I decided to try creating my own custom controls. This one performs as I want in 520 lines of code which is held in two behavior buttons. If the layout needs changing it is a simple matter to edit the template polaroid.
If I need a table then I use Bernd's modTableField.
best wishes
Simon
Re: Design philosophy of a Custom Control.
Posted: Tue May 21, 2019 5:26 pm
by Simon Knight
Re Library Stacks.
I don't think that they are applicable here as each component would still require code to call the scripts in the library. Also any library scripts would have to be told the identity of the calling object which might be a challenge.
best wishes
Simon
Re: Design philosophy of a Custom Control.
Posted: Wed May 22, 2019 4:16 am
by jacque
I sometimes script one of the buttons (or in your case, two buttons) normally for the first set in the control and then use those original buttons as the behavior for all the others. There is no reason that a button can't be an active control as well as being a resource for a behavior.
The only caveat here is that you can never, ever delete the first group containing the scripted buttons.
Re: Design philosophy of a Custom Control.
Posted: Wed May 22, 2019 2:19 pm
by Simon Knight
Jacque,
Thats a brilliant solution - why didn't I think of that ?
I have followed your advice and created an initialise routine in the group script:
Code: Select all
on preOpenControl
## Sent before the group is displayed
PhotoViewerInitialise
end preOpenControl
On PhotoViewerInitialise
## Handler updates the paths to the behavior buttons that store the code of the photoviewer group
## The buttons are part of the group, but are invisible.
## Only needs to be called once, does not hurt if called more than once.
Set the behavior of of me to the long ID of button "PhotoViewerBehaviour" of me
set the behavior of group "PolaroidTemplate" of me to the long ID of button "polaroidBehaviour" of me
set the locklocation of me to true
end PhotoViewerInitialise
I have attached my working control for review and comment :
thanks for all the advice,
Simon