[v1.7.3.5] ProfileChanging/ProfileChanged GUID always null

[Pfeil]

The 'ProfileChanging' and 'ProfileChanged' events added in v1.7.3.5 should pass the GUID of the previous and next/current profiles, however when running the following inline function and switching profiles, this does not appear to work:

Code: [Select]

using System;

public class VAInline
{
public void main()
{
VA.ProfileChanging += profileChanging;
VA.ProfileChanged += profileChanged;
}

void profileChanging(Guid? previousID, Guid? currentID)
{
VA.WriteToLog("Changing " + previousID + " to " + currentID);

if (previousID == null)
{
VA.WriteToLog("no guid");
}
}

void profileChanged(Guid? previousID, Guid? currentID)
{
VA.WriteToLog("Changed " + previousID + " to " + currentID);
}
} Writing "Changing  to ", "no guid", and "Changed  to " to the log(making the methods public explicitly did not change this).


EDIT: Not an issue, working as intended.

[Gary]

Your main exits immediately.  The function is called, the events are assigned and then it exits.  A function that exits immediately wouldn't care if the profile changed.

Try changing your main to this:

public void main()
{
    VA.ProfileChanging += profileChanging;
    VA.ProfileChanged += profileChanged;
    while(true)
    {
         System.Threading.Thread.Sleep(5000);
         VA.WriteToLog("Alive", "orange");
    }
}

[Gary]

Also, 'Changed' would only be for functions that run asynchronously - that is, they are not flagged with, 'wait until finished'.  Otherwise when the command is stopped (due to profile change) and the event would not (well should not) fire.

[Pfeil]

A function that exits immediately wouldn't care if the profile changed.

In the context of using an event handler to affect a running inline function, no, but these events could be (ab)used for other purposes.

Try changing your main to this:

public void main()
{
    VA.ProfileChanging += profileChanging;
    VA.ProfileChanged += profileChanged;
    while(true)
    {
         System.Threading.Thread.Sleep(5000);
         VA.WriteToLog("Alive", "orange");
    }
}

Copied verbatim, same result(GUID remains null).

The function is running asynchronously, if it's not the event handlers don't appear to run at all(as is expected behavior).

[Gary]

Now that I'm thinking about it - Did you happen to change your internal id to something non-null?  That is, you'd have to export your profile and then import it with an internal id (this function is for pack authors that need to know when their pack(s) are changing).  Forgot that part o_O

[Pfeil]

Aha. That explains things.

As profiles have an internal GUID in their .vap(the "Id" field), I assumed it referred to that.

I was wondering how the GUID would be predictable, as it's changed on export(and import?), but being user set that wouldn't be an issue of course.

I did see

Added, 'InternalID' author flag to profiles.  This is a nullable Guid (GUid?) value that can be supplied by authors to identify individual profiles.

but didn't put two and two together(I don't personally use profile flags, if that's an excuse).


Scrolling up in the documentation it's mentioned that it's an author flag in the "GetProfileInternalID()" entry, but because these events are in their own section and preceded by the queue methods I didn't see it when searching the pdf for the event names directly.


Now that I've set that value in the .vap, the inline function works as intended(even without the main loop running).

[Gary]

I'm going to add another out parameter that will be the profile name if somebody may need that (folks doing more simple stuff). 

I added the internal ID to provide a more specific way to identify a profile - AuthorTag1 is a string value and *could* be used for that, but forcing the use of that property for ids would have been not so great.