"Global_Init" and "Provider_Startup" get called multiple times while loading

[wirebirdlabs]

It appears that "Global_Init" and "Provider_Startup" get called multiple times while loading (they each get called the same number of times). I've not tried to fully characterize how many times these are called, but anecdotally, it appears related to the number of items in the project (more items == more calls to these functions). And just to quantify "called multiple times", that's between 1 and 6 calls.

This is not vital, just curious to know: what events trigger these callbacks?

Thanks!

[David_L]

Hi Jack,

Not too sure about this.  I did some basic tests and it seems regardless of how many items in the project, both the Global Init and Provider Startup VIs were called only once at LabVIEW startup and once at project launch.  What did you do to see multiple calls?

My test:  LabVIEW 2011 and LabVIEW 2012 using the Secondary Provider Example. I placed a one button dialog in both "SecondaryProviderExample_Global_Init.vi" and "SecondaryProviderExample_Provider_Startup.vi".  I had to create the Provider Startup VI and alter SecondaryProviderExample_Provider_Interface.vi to account for the new file.

When loading LabVIEW, both VI's run once each, when creating a new project both VIs run once and when loading any existing projects both run once.

I might be able to get a better more concrete answer, but the developer who knows the details on this is out of the office.  I'll check with her once she returns and try to get some more info.

David

[wirebirdlabs]

Thanks for looking into this! Again, we can treat this as low priority, at this point it's still just a curiosity.

Inside both of my "Global_Init" and "Provider_Startup" callbacks (and every single callback), I have a little logger VI that does the quick and dirty job of execution tracing the last 32 project provider callbacks:

That gives the following results:

Also, interestingly, three shutdown almost immediately after launching at the time 9:30:14AM. Could these multiple calls be related to the number of lvclasses in the lvproj?

[MikaelH]

This is true, the Global Init gets called a lot, I've not understood that as well.

I also think it get called when you add items in the project tree.

Jack, be careful in your provider code, if you add an item (e.g. a class like I do a lot) in the project tree, LV will call some init VIs from your code. That means your provider code (that added the item is still running), and at the same time another VI will be called by LV, this easily crashes LabVIEW.

I had to solve this, by adding a 150ms delay in my code always when I add an item to the project tree (i.e. causing LV to run a Provider.Init VI), basically wait before continuing my code so all INIT VIs have finished executing before I continue.

I looks like the application instance that is used for the provider VIs don't handle multitasking so good.

[wirebirdlabs]

Certainly useful information, thanks Mikael! I have found 3 ways to crash LV so far, but they have all been due to errors I made; but will certainly look out for this one you mention.

[David_L]

It is strange that I cannot get my code to trigger Global_Init more than once but I do know I've seen this behavior in the past.  I'll talk with Sumedha to try to find out what may cause it, but it might be a much deeper investigation into the LabVIEW source code to find out anything useful..

In the meantime, I would suggest assuming that the VIs will be called an indeterminable amount of times, and add code that accounts for it, such as using "first call" or the info you have stored in your shift register already.

Mikael, you are correct that the Project Provider application instance does have many unknowns to it and sometimes shows strange behavior.  This is why this feature never was truly opened up externally until recently and why we only open it to a limited (and exceptionally brilliant) audience.  Of course our goal is to fix any of these problems moving forward.  If you discover any obvious problems with providers, please don't hesitate to bring them to our attention so we can CAR and (hopefully) fix them.  This includes crashes, unexpected behavior or even subtle things such as poor documentation or missing functionality.

David

[Mellroth]

Hi Jack,

I don't have a solution to your "problem" but when we debugged the App Builder Support, we also created a LV2 global much like yours. The difference was that we also used the ObjectID to get the project item that was causing the Provider method to run.

/Jonas

[wirebirdlabs]

Mellroth wrote:

Hi Jack,

I don't have a solution to your "problem" but when we debugged the App Builder Support, we also created a LV2 global much like yours. The difference was that we also used the ObjectID to get the project item that was causing the Provider method to run.

/Jonas

Clever! A little refactoring of the execution trace logger gives this:

 

I'm scratching my head as to why Provider-Shutdown events (log items 015-017) do not have an Item ID that corresponds to any of the Provider-Startup events (log items 001, 003, 005...), but these are questions that I will not investigate right now - perhaps later, if application functionality dictates.

[Bas.v.E]

---

@wirebirdlabs wrote:

I'm scratching my head as to why Provider-Shutdown events (log items 015-017) do not have an Item ID that corresponds to any of the Provider-Startup events (log items 001, 003, 005...), but these are questions that I will not investigate right now - perhaps later, if application functionality dictates.

---

I know why, and this is something that is not documented. When I look into the "Project Provide Interface Documentation" found on this page, I'm seeing that the input of the provider vi's are not always Item ID, like in the Provider_LoadComplete.

Provider_LoadComplete
Description: Called when the project has finished loading.
Inputs:
 ItemRef Project Reference to the project
Outputs: None

Here you can see that the input is a project reference. I tried type casting this ID to a project ref but I this didn't work, so after some digging I found out that the normal ItemRef is a U64, but a normal labview reference is a I32, so after swapping the ItemRef with an I32 or with a project reference control I would get a valid reference to the project.

To add to this, I also found out that the Provider_shutdown.vi is not only called when the project is closed like described in the documentation

Provider_Shutdown
Description: Called when the project shuts down.
Inputs:
 ItemRef Project Reference to the project
 Boolean Is LV Exiting? Specifies whether LabVIEW is exiting (true) or not
(false)
Outputs: None

But also gets called when code closes the reference to that particular project. like other providers or other code.