Recently I decided to build my own variation on bar snapping. After several days of work, I have a pretty strong bar snapping module. If you are not sure what bar snapping is then, here goes:
We collect the coordinants for all of frame's points (TopLeft, BottomRight, etc). After that,
we compare those points to all of the other Magnets enabled frame's points to detect if two points are close enough to snap together. When docking frames together, only certain points can snap to each other. So, for example, the TopRight of the frame can only snap to the TopLeft of another frame. A frame may also dock to corners and middle points of edges of the screen.
My thought is that I could get a few people to look over my code to check for performance issues or other random bits of concern. Here's a link: Magnets
Thanks to anyone who cares to take a look and let me know what they think!
There are three things that I would point out, in order of reading the file:
1) After the line Magnets = Magnets or { <stuff> }, I suggest adding local Magnets = Magnets. That way all the references for the rest of the file go through the more efficient local.
2) The function GetPointInfo returns a freshly-created table each time it's called. Unless this is called rarely (would need to measure it to be sure, even if only by adding a print() call), it's probably creating a lot of churn in the garbage collector by doing so. Consider replacing the table by a list of return values instead, and then either iterating across them or copying them into a (more) persistent table.
3) You're using the keyword 'self' in your Magnet methods to refer to frames passed in by the client code. There's nothing inherently wrong with that, but it can be confusing in future -- your function Magnets:whatever() ... end definitions that do NOT take a parameter named 'self' would still be able to use that keyword, but it would refer to the Magnets table instead of a client frame, and you would get no warnings or errors about the potential ambiguity.
I plan to soon. The code I posted was just the bar snapping related stuffs. I intend to use the code in my unit-frames addon, so I want to extend on what this lil module will be able to do for me.
Recently I decided to build my own variation on bar snapping. After several days of work, I have a pretty strong bar snapping module. If you are not sure what bar snapping is then, here goes: We collect the coordinants for all of frame's points (TopLeft, BottomRight, etc). After that, we compare those points to all of the other Magnets enabled frame's points to detect if two points are close enough to snap together. When docking frames together, only certain points can snap to each other. So, for example, the TopRight of the frame can only snap to the TopLeft of another frame. A frame may also dock to corners and middle points of edges of the screen.
My thought is that I could get a few people to look over my code to check for performance issues or other random bits of concern. Here's a link: Magnets FetLifeIMVUCanva Thanks to anyone who cares to take a look and let me know what they think!
Ho I didn't know they had a built in code poster Thank you so much
We collect the coordinants for all of frame's points (TopLeft, BottomRight, etc). After that,
we compare those points to all of the other Magnets enabled frame's points to detect if two points are close enough to snap together. When docking frames together, only certain points can snap to each other. So, for example, the TopRight of the frame can only snap to the TopLeft of another frame. A frame may also dock to corners and middle points of edges of the screen.
My thought is that I could get a few people to look over my code to check for performance issues or other random bits of concern. Here's a link: Magnets
Thanks to anyone who cares to take a look and let me know what they think!
1) After the line Magnets = Magnets or { <stuff> }, I suggest adding local Magnets = Magnets. That way all the references for the rest of the file go through the more efficient local.
2) The function GetPointInfo returns a freshly-created table each time it's called. Unless this is called rarely (would need to measure it to be sure, even if only by adding a print() call), it's probably creating a lot of churn in the garbage collector by doing so. Consider replacing the table by a list of return values instead, and then either iterating across them or copying them into a (more) persistent table.
3) You're using the keyword 'self' in your Magnet methods to refer to frames passed in by the client code. There's nothing inherently wrong with that, but it can be confusing in future -- your function Magnets:whatever() ... end definitions that do NOT take a parameter named 'self' would still be able to use that keyword, but it would refer to the Magnets table instead of a client frame, and you would get no warnings or errors about the potential ambiguity.
I was able to retain a somewhat streamlined approach, and add lil extra functionality to it. Lemme know what ya think.