Design philosophy of a Custom Control.
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 854
- Joined: Wed Nov 04, 2009 11:41 am
- Location: Gunthorpe, North Lincs, UK
Design philosophy of a Custom Control.
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
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
best wishes
Skids
Skids
Re: Design philosophy of a Custom Control.
There is no risk at all, I'm sure you'll get a few!I recognize that this is risky post as I'm asking for opinions but here goes......
I think it is, but ...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'm not sure that is the only alternative. Setting the code up as a library with the groups, for instance, might be an alternative.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.
For how groups really function, I'll pass for someone that actually knows what they are talking about
-
- VIP Livecode Opensource Backer
- Posts: 9824
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Design philosophy of a Custom Control.
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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Posts: 854
- Joined: Wed Nov 04, 2009 11:41 am
- Location: Gunthorpe, North Lincs, UK
Re: Design philosophy of a Custom Control.
I have no idea about libraries but will have a search of the documents.Setting the code up as a library with the groups, for instance, might be an alternative.
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.this particular control looks like exactly the sort of thing the DataGrid was designed to handle. Why not use the existing custom control?
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
best wishes
Skids
Skids
-
- Posts: 854
- Joined: Wed Nov 04, 2009 11:41 am
- Location: Gunthorpe, North Lincs, UK
Re: Design philosophy of a Custom Control.
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
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
best wishes
Skids
Skids
-
- VIP Livecode Opensource Backer
- Posts: 7229
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Design philosophy of a Custom Control.
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.
The only caveat here is that you can never, ever delete the first group containing the scripted buttons.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Posts: 854
- Joined: Wed Nov 04, 2009 11:41 am
- Location: Gunthorpe, North Lincs, UK
Re: Design philosophy of a Custom Control.
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:
I have attached my working control for review and comment :
thanks for all the advice,
Simon
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
thanks for all the advice,
Simon
best wishes
Skids
Skids