Jump to content

shoneill

Members
  • Content Count

    857
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by shoneill

  1. Did not know about that function. Nice.
  2. So your job is to make it as hard as possible for NXG to ever catch up with with LV 20xx? ๐Ÿ˜€
  3. It was listed as part of the roadmap, with the added caveat, that such extension would be available only in C#. I certainly remember it being communicated as the way forward with regard to replacing XControls. It was certainly used as a carrot, even if the word "promise" is not accurate. Then at the CAB in Austin some years back, we were told that won't be happening, that the existing control classes won't be extendable. I can't recall exactly who and when, but it was definitely communicated.
  4. Is the existence of XControls one of those bugs?
  5. I'm pretty sure XControls are dead in the water. But I sure hope they are working on an alternative, at least for NXG.
  6. My usage of it or not is completely irrelevant to the point I was trying to make. NI should be working on a proper implementation of extendable controls (C# inheritance was touted, then it turned out that will be limited / useless). I fear they are looking for a way out of that corner. But still, if we're realistic, there'll probably be notnhing of that sort coming in the next X years, so this IS a boon. I just hope this doesn't stop NI working on a proper implementation. I'm not casting any shade ont eh toolkit itself, it looks pretty amazing. The reason I think it might sway people at NI is because it IS good. If it would be half-arsed, I wouldn't be afraid. So from that point of view, technically speaking, ๐Ÿงก
  7. I don't think I am incorrect. It mimics the existing VI Server tree, but it does not extend it per se. I agree it's a great toolkit and has a LOT of potential, but it's just not the same. I've done something very similar, I'm aware of the benefits and the limitations of this type of implementation. Code changing properties of the control in parallel to the LVOOP approach can be very hard to manage.
  8. I agree completely, but will NI spin it differently?
  9. In end effect what we need is the ability to actually inherit from existing controls in order to extend their functionality. Just being able to extend a String control to allow for a dictionary should be possible without it being distinguishable from a "normal" String control on the FP or BD (Perhaps for some identification on the BD of it being an extended control). XControls never really offered this. Correct me if I'm wrong, but I don't think QControls do either. We were promised that NXG would get exactly this kind of extensibility, but having heard nothing more on it (and a few rumours to the contrary, I fear the worst). I have the feeling NI might use this as an excuse to see their promise of extendible FP controls as being fulfilled. For this reason and this reason alone I am skeptical and pessimistic. TL;DR. Technically yes. Politically and strategically no.
  10. One VI to rule them all, one VI to find them, One VI to bring them all and in the darkness bind them.
  11. To make sure no Events are lost I usually just register the user event at the moment of creation and pass out the event registration refnum for the event. Then, any events sent before the Event loop is running are not lost, they are stored within the event registration refnum queue. A different idea is the ability to get the last sent value. I typically involve the event loop in this as it "owns" the values and other processes may actually update the values (such as internal consistency checks) so that the last "sent" value is not actually up-to-date. But I canunderstand the idea behind being able to efficiently get this value back.
  12. I had a look at the code, but I guess it's lost on me a little. So the idea is that the code allows for stateful sending of events, that one can recall immediately the last value sent via Event (stored in a Notifier)?
  13. Separate out the external Queue from the internal one. If the internal queue has elements in it, ignore the external queue. Only read an element from the external queue when the internal is empty. You can extend this to N layers by maintaining a stack of queues, where element zero is the external queue (should never be destroyed). All internal states which enque further states do so on a newly-created internal queue and pushes all other queues down the stack. This way you get deterministic execution of your states. Guaranteed execution order without interruption and a way of investigating the execution flow (depth of stack and so on). Of course when an internal Queue is empty, it is destroyed and the top-most queue is retrieved from the stack. I keep coming back to the definition of a "Pushdown Automaton" even though it really does not fit, but it helps me to visualise what's going on. Imagine that the input tape and the stack are the same thing. Each input tape is an element of the stack. Pushing and popping input tapes allows you to essentially create subroutines.
  14. Nice. Never heard of that one before. Fits nicely.
  15. Maybe it's a new version of the Marshmallow test.
  16. It would be nice to have a changelog accessible before having to download the installer first.... All I see is a critical patch link, but this doesn't look like a changelog to me at all. Have I missed something?
  17. BTW, the ability to connect a NULL reference is intended. This way, you can switch off certain events by modifying the Event Registration Refnum entries with NULL values. I have code where I register for certain events outside of a loop with exclusively NULL references, only to have a different event actually deliver the correct event references to listen to. This way the Event registration refnum is created at initialisation but remains essentially inactive until "primed".
  18. Why would there be a coercion dot on the input of a function whose name implies it is being used for a coercion? The fact that a coercion is taking place is obvious due to the presence of the node for doing the coercion...... That aside, I think the addition of type safety would be a welcome additional function. But does your function allow us to coerce a U8 to a U16 for example? Here no data is lost and it should be completely safe (under the assumption the programmer knows what they are doing).
  19. Hmm, maybe the manual "Save As..." and the Programmatic "Save As..." are not equivalent? Or memory fails me. I thought it wasn't neccessary to replace the controls if doing a manual "Save As...".
  20. which is basically just automating what I said above..... Do you really need to change the controls? When you do a Save As from LV, it changes the type of the controls for you.....
  21. Right-click the Default class in project and choose "Save As...", then create an unopened copy. You only need to rename the terminaly, but there's a quick drop shortcut available for that somewhere (rename labels). You need to manually change inheritance.
  22. A Class knows only it's parent, not it's grandparent before being instantiated. Dynamic loading of classes prevents knowing this beforehand.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.