Design philosophy of a Custom Control.

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

Post Reply
Simon Knight
Posts: 477
Joined: Wed Nov 04, 2009 11:41 am
Location: Gunthorpe, North Lincs, UK

Design philosophy of a Custom Control.

Post by Simon Knight » Tue May 21, 2019 9:27 am

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 :
Screen Shot 2019-05-21 at 09.03.36.png
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

bogs
Posts: 3932
Joined: Sat Feb 25, 2017 10:45 pm

Re: Design philosophy of a Custom Control.

Post by bogs » Tue May 21, 2019 11:32 am

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! :D
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 :wink:
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6960
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Design philosophy of a Custom Control.

Post by FourthWorld » Tue May 21, 2019 2:47 pm

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
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Simon Knight
Posts: 477
Joined: Wed Nov 04, 2009 11:41 am
Location: Gunthorpe, North Lincs, UK

Re: Design philosophy of a Custom Control.

Post by Simon Knight » Tue May 21, 2019 5:21 pm

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
best wishes
Skids

Simon Knight
Posts: 477
Joined: Wed Nov 04, 2009 11:41 am
Location: Gunthorpe, North Lincs, UK

Re: Design philosophy of a Custom Control.

Post by Simon Knight » Tue May 21, 2019 5:26 pm

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
best wishes
Skids

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5138
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Design philosophy of a Custom Control.

Post by jacque » Wed May 22, 2019 4:16 am

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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Simon Knight
Posts: 477
Joined: Wed Nov 04, 2009 11:41 am
Location: Gunthorpe, North Lincs, UK

Re: Design philosophy of a Custom Control.

Post by Simon Knight » Wed May 22, 2019 2:19 pm

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 :
WIP_PhotoViewer Internal Behavior buttons.livecode.zip
Beta of custom control PhotoViewer
(8.61 KiB) Downloaded 32 times
thanks for all the advice,

Simon
best wishes
Skids

Post Reply

Return to “Talking LiveCode”