GregFreeman

I like this solution. Also, if as mentioned above, I check the current VI reference in the subpanel against the VI reference I'm about to load, I can have some logic built in determining if I need to remove the current panel or not, or even load a new one (if the references are already equal, no need to remove or load).

I don't mind this idea, the one thing I wasn't sure of is the fact that now the main VI which owns the subpanel has access to all the other VIs references. To me, it feels like these references should be private and other VIs shouldn't have access to them. Maybe I'm splitting hairs here though. Always the community scope/friend route but I try to avoid that if possible.

Good points above. And James, you're right I could easily pass the subpanel reference as message data.

This should be relatively simple, but I'm not seeing a good way to do it. I start up a bunch of VIs that run in parallel. Each VI has a reference to a subpanel which they can be loaded into. The user can then select different screens and whichever screen they pick will be shown (pretty standard). When they are unloaded from the panel, they unregister for all events except changeView and exit, so essentially they will just sit idly and hidden. My problem is with the unloading of a panel. I can send a change view event which the visible view will receive and it will remove itself from the panel. The view to be shown will receive the event as well and load itself. With this method, however, if the view to be shown receives the event first, it will try to load itself before the other view is removed which I believe throws an error. So, I have thought of a couple of solutions. I could have my top level view which owns the subpanel remove the VI before sending the "change view" event. That way the view would be unloaded and it could just unregister and do any cleanup in the background. Another option is that I can make separate hide and show methods, making the hide method synchronous and wait for a response. Or, I could have the view with the subpanel hold references to all the different views and show and hide them directly (I really don't like the first or last approach; it seems to break the messaging paradigm of parallel processes. I'd rather use messages and let the VIs load/unload themselves. But, I also tend to shy away from synchronous messaging, which basically strikes out option 2 leaving me with nothing). Anyways, wondering if anyone can provide some insight here.

Potentially, but I am taking a bit of a break from this for a couple days. When I get back to it I'll have a look.

Well, therein lies the problem. I am not actually exposing the inner workings because the get current block method I have shown is private. The Executive Functionality class already owns the list of blocks. This private method is just so I don't have to put an index array element 0 everywhere I want to get the first block in the list, but instead can encapsulate that functionality into a method in case the way we determine the "current block" ever changes (which is probably won't but this is just one use case. This could be an issue with other private methods that have more advanced functionality to determine what to return). Part of the misunderstanding here is probably due to the fact I wasn't clear that the "Get Current Block" method isn't just a normal getter but has some additional logic inside of it. That's not a bad idea. Thanks guys, I figured there was no clear cut answer but this at least points me to some different ways of mitigating the problem.

I am curious how people have handled this issue seeing as LabVIEW is by-val. The attached screenshot shows me accessing a particular class's private data using a private method (note, I'm not pulling private data outside the class to modify it, just using a private subVI to keep some stuff clean). But, then the block's private data is updated in one of the methods that is called, so it needs to be rebundled. However, there is no clear way of showing that a particular method has modified private data within itself. Are there any conventions you guys use to indicate that a method actually modifies private data? Or, do you just make the assumption that any method modifies private data and needs to be rebundled unless it's a getter or setter?

If you are on a non windows OS, you could use the "get file/directory info" VI and just monitor the last mod timestamp. Then only call the directory listing once at startup to get the initial list, and any time the last mod timestamp changes. This reduces the number of times it needs to do the list/compare.

I'm not sure if I agree or disagree with the auto indexing. I see strings in LabVIEW as a class ultimately representing an array of bytes, but not actually being an array of bytes themselves. To this point, adding the autoindexing ability to strings seems a bit off because the string itself is just one thing. That said, I understand your side of the argument as well; if it represents a byte array, shouldn't you be able to do work on it like it's a byte array? How is this handled in other languages when you iterate on a string class? Even in JAVA I think you have to convert to a character array, no? Or at least iterate over charAt(i). This is just a guess. It is an interesting questions none the less. Just curious, how would you implement autoindexing of a string? Would it return a new "char" data type, a u8, either, etc?

If my application has a File menu, it is my gut instinct that the exit should be there. That is my expectation because that is what I am accustom to. That doesn't mean I, or anyone else actually uses it, but I still feel it's expected. Whether or not that is the right place for an exit menu item is obviously debatable, but Microsoft has dictated that in the past and I feel consistency with the environment that a user is familiar with is most important. However, environments are changing. What is familiar to me is fading (can I just have a tools->options.. menu in Word, please?). But, if the ribbon is all one knows, which is most likely the case with the youth of today, then a tools menu to them may be what the ribbon is to me (confusing). File -> Exit may still be expected for those of us who went through the past few decades, but in that case are we the right people to ask this question to? Who knows what will come next. Will those expectations remain? For how long will they remain? What platform we are on dictates these sorts of things as well. Notice, you can change configuration settings on your phone, but there is no need to press save. Does that mean we should remove a save button from MS Word? Probably not (although auto save seems to be common in many applications now). So, I haven't given you a clear answer, per se, but I am just vomiting out all my words through my fingers and hoping they provide some insight.

Oh man, just learning this? You are gonna love avoiding those for loops with format into string!

This was the assumption I made as well.

Just curious, is there any fundamental difference between using the in/out element in an in place element structure versus just using the generic node you get when crossing boundaries (I just realized I don't know if there is an official name for this node).

I just pulled in new changes and am getting a similar "typedef" changed message in other files. The strange thing is, I can't find a typedef in the class anywhere? Maybe it's coming from a static dependency, but a brief scan of stuff doesn't show anything. Unfortunately in this case, no property nodes are used. However, almost all the VIs that LabVIEW says have "changed" are accessor VIs. There is some parallel between these things, that's for sure. Maybe I'll just use static VIs instead of accessors in property definition folders from now on and see if that alleviates the issue. Edit: one additional thing I've seemed to notice is it is often (not sure if always) a child class that has these issues. Maybe just a coincidence, butit seems my base classes don't have a problem. Note though, this isn't confirmed.

Sorry to resurrect an old thread but I am currently running into a similar issue. The only commonality I can find is property nodes are used in the VIs. When I click list unsaved changes, all VIs in question say "Some VI Attribute Modified" and in the details say "Some attribute of the VI was changed, such as the breakpoint, data logging, or VI Properties options." This is causing frustration when using Git because there are changes to the binary apparently that aren't captured by a diff and everyone having to resave is causing conflicts that don't really exist in terms of code functionality changing. I am going to branch the code, replace the property nodes with accessors and see what comes of it. But, in the mean time I figured I'd see if anyone else has determined anything further relating to this in the past 2.5 years. Edit: I should note, I just realized once I save locally the dirty dots don't reappear. But after a merge they often do. Maybe it's some discrepancy between a project my coworker is using locally and mine (autopopulating folders or something). Just speculation; I'll dig into it more. Also, I have source code separated from compiled on these files.

Suggested Link I like that link. Gives a good basis for things. I, however, prefer my frameworks to dynamically launch actors because when I do truly require something to be launched dynamically such as multiple windows etc, the caveats are already built in (who owns the lifetime of the queue refs etc). On RT though, I tend to use static processes since not much is ever launched dynamically, except my TCP manager I reuse. I wouldn't think of an actor in too complex a way. You have been using actors all along, even if they are not OO. It's just a parallel process that is used to accomplish a specific task. What is nice about OO is you can make the incoming queue reference to an actor private, forcing you to define public methods to send it messages, leaving you with a nice API of what the actor can do. Dave shows this nicely in the thread that I have linked. It should be noted, queues are not the only way to implement actors, but I find them to be the most straightforward transport mechanism when transitioning to OO Actor Oriented Programming.

Absolutely, 100% agree. This is the most important advice you will get. As day-to-day developers it is so compelling to implement actual code; don't do it. Describe first, then if you have time you can go back and fill in as it permits.

Have you tried making a debuggable executable and attempted to connect to it? Also, have you right clicked and selected to deploy after you do the build? I assume so but it's worth asking.

Definitely. Let's chat. I'll seek you out once I have a better idea of my schedule. Check your PM's, I'll send you my email address.

Let me take the weekend to gather what I have and jog my memory so I can explain how I got to the point I am at.

Paul, no problem we can catch up on this later. That said, do not fully take my advice because I just noticed some changes missing from my merge. I think I resolved some conflicts incorrectly . Part of the learning process! Also, with regards to the path, the way I was getting around this (although i still didn't get things to fully work) is write a shell script that formats the path correctly, and that script was invoked upon calling of the difftool. If you are still playing around with this, maybe I can send to you what I have as a starting point. Edit: figured out where I went wrong with my merge conflict resolution. Resolve using Mine/Theirs did not do what I thought. It didn't use my working copy, which is the one I made changes to during the diff. I should have staged my working directory file in source tree and resolved the conflict with that (not mine, or theirs). I'm going to stop flooding this thread though, as I have somewhat gotten it off track from the original question. That said, Paul, are you going to be at the CLA Summit? I'd love to take some time to sit down and talk about these workflow things, and other trials and troubles we have come across, to help prevent potential future issues.

Paul, I have a follow up here that I wanted to post. I just got done doing a Merge with a few different conflicting files, and I was able to do it successfully, without the merge tool or diff tool integrated directly into source tree. I spent time yesterday trying to get things to work with source tree but was unable to successfully do so. However, I got close, so I may hack away at it more later. I basically did what I mentioned the other day with opening the before and after, but wanted to get into a little more detail. Our company is currently using git flow within source tree, or a loose version of it anyways. I don't always use the gitflow button when finishing things up, but usually do to start features, releases, etc. This is mainly because I want more fine grained control when finishing a feature versus starting one just because I see more potential for issues when bringing code together versus branching off from existing, up to date code. This may be me worrying too much, but for now it seems to work. So, here is how I handled things. My feature wasn't done but the develop branch had changes made to it which I wanted to incorporate into my feature branch to keep everything relatively in sync. After all, the longer you wait to merge, the more issues you will run into. However, I really didn't like the idea of merging develop into feature, because I thought it may be easy to overlook or misunderstand my coworkers changes should I have to pull them into my copy. Therefore, I felt it was better for me to merge my feature branch into develop and move my changes into develop's copy of the file. So, I checked out develop and selected to merge feature into develop. On conflicting files, I used open before and open after to open both, then ran LVCompare on them, moving my changes into the develop branch's copy of the file. I saved the file, then resolved using the develop branch's copy ("mine"). One this was done, I committed the changes. Now, develop was one commit ahead of my feature branch. But, because my changes from my feature were already applied in the develop branch (from my diff and merge), now I could just merge from develop back into my feature branch (which should work seemlessly, with no conflicts). Now both my feature branch and develop branch are pointing at the same commit, and I can continue working on my feature branch which has both its changes, and develop branch's changes. Does this make sense?

You've done it correctly. I wasn't implying anything with regards to the way LVOOP works, but instead was referencing a bug I caused. Here is an example: I just know in the past I have put something in a child class, then decided it needed to be in the parent. So, I moved it to the parent but forgot to delete it from the child when I did so. Now I had a variable A in my parent and a variable A in my child. Then, down the road, I started setting variable A in the child class, but accessing variable A that was in the parent, which just kept returning a default value. Does that make sense? It was a bug entirely inflicted by me on myself Edit: threw together a quick example of what I had done, and attached it. Not using property nodes, but you get the idea. Pretty confident this isn't causing the issue you are seeing though, but I'll add it for clarification to my rambling anyways. New folder.zip

This is a complete guess, but is it possible that you mistakenly have a nPixels data member in both a parent and a child, and you are setting/accessing the wrong one? My guess is this is not it as Michael suggests he has seen similar behavior before, but it is worth throwing out there.

I think it was actually Crossrulz that made me aware of this tool which is usually my go-to for this sort of thing. Otherwise, I end up opening the project and accidentally saving out of habit and then having to roll back through version control. However, this will only show the version of the file you clicked on, so it doesn't help if your project was saved in 20xx but a couple VIs are a different version for one reason or another. In that type of scenario, I think you'd have to go with the method mentioned above to verify all.