Error in Pre Launch-Init override

[jtagg]

Thanks. That confirms what I was thinking.

I also thought of doing a Pre-Launch Init Core but decided against it for now because I was hoping to minimize changes to the way people already use AF. I want my common ancestor to keep the flexibility of vanilla AF and not impose anything if it can be avoided.

In my case, my ancestor Pre-Launch shouldn't generate any errors (maybe I shouldn't be so confident...but I do try to make that guarantee) so I'm content to leave it as it is. I may need to change in the future if new stuff gets added to Pre-Launch Init however.

[Taggart]

sounds like a great feature for NXG...

But yes I agree, Allen's solution does work well for simple situations, but it does break down.  It doesn't handle situations like "My parent opens this reference in it's prelaunch init and I want to do some thing to that reference like for example setting the range on an instrument, or adding something to the header of a file." or similar situations.

[AristosQueue (NI)]

---

@Taggart wrote:

sounds like a great feature for NXG...

---

The AF in NXG will come across as it stands today. BUT... I do hope in the next few years to roll something new that replaces the AF with something much more native, complete with debugging, etc., that does away with a lot of the artificial file complexity of the AF. AF is a library built out of today's language. I'm hoping for something more built into the G language. It's a heavy task to get buy-in for that from The Powers That Be, but I think we've learned enough from the AF in the field to build something better. Fingers crossed.