Global Variables || Global Icon Paths in namespaces?
-
I want to create a namespace with all my icon 'paths' saved as 'global' variables so I can just call on them from anywhere when LAFing. I dont want to keep them in onInit script if possible. Is this a good practice?
If not can you recommend a good way to keep these long path strings in order somewhere?
Thanks!
-
@Chazrox Why are you "LAFing" anywhere else than in your main interface script?
-
@Christoph-Hart is that a bad practice to have my LAF functions in an external script / namespace?
-
@Chazrox said in Global Variables || Global Icon Paths in namespaces?:
Is this a good practice?
Using an external file is good practice. Don't use a global variable though. Just import the file into each script you want to use it in.
Your question brings up something I was wanting to ask Christoph too. If we build a fancy GUI for non-interface midi processors, how does that affect performance? Will it all be stripped out at compile time?
I was considering doing this because I thought it might make some of my scripted modules more approachable for other developers.
-
@d-healey said in Global Variables || Global Icon Paths in namespaces?:
Just import the file into each script you want to use it in.
Thanks.
-
@d-healey said in Global Variables || Global Icon Paths in namespaces?:
more approachable for other developers.
I think this is always a great idea!
-
. If we build a fancy GUI for non-interface midi processors, how does that affect performance? Will it all be stripped out at compile time?
No of course not, but the paint routines might not be called until the interface is visible. Timer callbacks might be executed though.
I was considering doing this because I thought it might make some of my scripted modules more approachable for other developers.
Can you make an example of what customization makes internal scripts "more approachable"?
-
@Christoph-Hart said in Global Variables || Global Icon Paths in namespaces?:
Can you make an example of what customization makes internal scripts "more approachable"?
Here's a script for handling guitar picking
Here's the front end view that the users see
Making the back-end look a bit more like the front end would make it easier for developers to understand how the two things relate, without having to look into the script so much.