# Best practice regarding registerMethod()
**URL:** https://discourse.processing.org/t/best-practice-regarding-registermethod/26008
**Category:** Development
**Created:** [December 7, 2020, 2:03am UTC](https://discourse.processing.org/t/best-practice-regarding-registermethod/26008 "2020-12-07T02:03:07Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@delsey](https://discourse.processing.org/u/delsey)
#### Post date: [December 7, 2020, 2:03am UTC](https://discourse.processing.org/t/best-practice-regarding-registermethod/26008/1 "2020-12-07T02:03:07Z")
I’m writing a library, mostly for my own purposes but also because I wanted to learn how to do it. It consists of gui-elements such as buttons, switches, dropdowns, etc, structurally close to cp5, but I decided to start from scratch because I was only able to achieve what I was trying to do with really “hacky” solutions.
As the documentation for creating libraries seems kind of thin and sometimes deprecated, I ended up with a bunch of classes, each getting the current PApplet in their constructor and each registering a draw-method. The problem I’m running into is the missing functionality of being able to set the order of which the registered methods are run in. They’re always called in the order the objects were initialized in.
The problem this causes, is that if the draw() of a button that is placed below a dropdown is registered AFTER the draw() of the dropdown, the button will draw over the dropdown when it’s open.
Placing the button somewhere else basically defeats the purpose of a dropdown, as its supposed to give different options while not taking up as much space. The only way to work around this, is to always create the objects in a certain order, eg buttons first, dropdowns always last. I was not able to find any other solution to this, but I might be missing something obvious. This certainly isnt that big of a deal, but it just doesnt feel like a satisfying solution and its also kind of counter-intuitive. I havent used cp5 alot and also havent looked into its code, but I’m guessing one of the reasons it needs the controller is being able to control the order that its draw methods will be called in. (or it probably does some other smart stuff to reach the same solution)
Is there a solution to this that I am missing? Is the passing of the PApplet to each gui-object “good practice”? Is there a way of controlling the order of the calls made to registerMethod() without a controller-class managing all gui-elements? Is my library structurally wrong? - If so, any tips?
Sorry, if it’s hard to understand without any working code, but I don’t want to make the library public in its current state.
Thanks in advance
---
### Author:  [@micycle](https://discourse.processing.org/u/micycle)
#### Post date: [December 7, 2020, 11:52am UTC](https://discourse.processing.org/t/best-practice-regarding-registermethod/26008/2 "2020-12-07T11:52:14Z")
I can think of three solutions.
If your GUI elements are in two groups of ordering (i.e. dropdowns at the front, with everything else at the back) then you can register and override the `pre()` method to draw everything else at the back (`pre()` is called at the very top of the `draw()`), while using `draw()` to draw dropdowns at the front (registered `draw()` are called at the very end of `draw()`).
* * *
A controller, as you’ve mentioned, that the user calls to add GUI elements.
So instead of creating `Dropdown d = new Dropdown();`, a user would create one with the controller: `myLibrary.addDropdown(...)`, or `Dropdown d = myLibrary.newDropdown(...)`.
* * *
A static controller (which is hidden from user view).
In this case we’d use `Dropdown d = new Dropdown();`, and the constructor of `Dropdown` calls a static method in your library to unregister and re-register GUI elements as necessary.