XOJO 2021r1.1 / Windows Desktop
How can I make a Memoryblock Global and available in the whole App ?
Regards
XOJO 2021r1.1 / Windows Desktop
How can I make a Memoryblock Global and available in the whole App ?
Regards
Create a Module. Add a property to the module called test of type MemoryBlock with a Scope of Global. You can then use this property name, test, from anywhere in your code.
See https://documentation.xojo.com/getting_started/using_the_xojo_language/modules.html under Scope of Items > Global for more info.
That’s what I was doing, but that doesn’t work for a memoryblock.
Therefore my question about a global Memoryblock.
Create a Module
In this module create a Property ‘mbTest As MemoryBlock’ with scope Global
In the same module create a method to put some data into this memoryblock
Refering to this newly created memoryblock (mbTest) in another Window’s method results in a Nil exception for mbTest.
You still need to initialise the memory block.
It may be good to add some kind of Initialise method to the module and then call that one from app.open or app.constructor.
And in a similar vein, you could make it a property of the app
Then initialise it during the app.open event
and refer to it through your code as app.mbTest
If you make properties in app, please make them shared to increase performance.
I don’t ever remember hearing that before. Why does this increase performance?
Nor me.
BUT I do recall that creating a global variable called theapp in a module, and setting it to = App
then referring to theapp.stuff instead of app.stuff
is faster.
Why? No idea, but it was so when I tested that years back
See blog post: Tip of day: Make variables in app shared
This tip has been out there since 2014 and I never knew it? Guess it is time to review many of you blog posts…
good idea. Just work yourself backwards: Our Xojo Blog
Every now and then I stumble upon performance tips (like Christian’s) in this forum and think I wish I had known that before.
The first one I remember is storing the last index in a variable before looping instead of calling .LastIndex each iteration, the latest is the recent discussion about if…else vs. if() regarding Strings.
I wonder if it wouldn’t be useful to collect such tips in a separate thread (just the facts, no discussion) – it would be a really valuable ressouce in my opinion …
Regarding caching the LastIndex of an array, we did this test years ago, but I just did it again now.
The bottom line is, yes, it’s faster to cache, but the difference isn’t worth the trouble.
With code that fills an integer array of 100M (!) elements, I get these results:
Default Optimization
Array Count = 100,000,000
LastIndex = 955.6 ms
Avg = 0.010 µs
Cached = 725.8 ms
Avg = 0.007 µs
Aggressive Optimization
Array Count = 100,000,000
LastIndex = 367.8 ms
Avg = 0.004 µs
Cached = 229.8 ms
Avg = 0.002 µs
Unless you are trying to squeeze every last millisecond, I wouldn’t bother with the extra code.
That was just an example and sure enough it won"t make a big difference on today"s M1 machines.
Still, I like those optimizations and several combined did make my apps snappier in the past.