Global Memoryblock

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.

1 Like

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.

1 Like

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

2 Likes

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.