Michael Aivaliotis

I was already subscribed and looked at what my podcast player (Apple podcasts) was using as the URL. So ya, I cheated.

Well technically, an event frame is for user events. If you programmatically resize the panel (which is not a user action), then it's your job to tell everyone to fix themselves. Sure we could argue forever on that one point. But it seems much less hacky to send a panel resize cleanup message than to jiggle the splitters. Imagine someone trying to read your code and figure out why you're jiggling the splitters.

Try this: https://anchor.fm/s/71f9ee0/podcast/rss Also, if you go to the podcast homepage on Anchor, click on the button that says: Listen in your favorite app.

I assume you already have a mechanism to send messages to these sub-paneled VIs? Could you use that?

Ya, that's strange. I tested it on chrome and safari and it looks fine for me. I notice the dots are working and the discussion round icon is dimmed. So it seems it's partially working, but not the bolding? What browser? Chrome?

The scrollbar is behaving as it should. I suggest you create property nodes for the scrollbar and investigate the help on those. When you create a brand new scrollbar it sets the DocMax and DocMin to 10 and 0 respectively. It uses that as a reference if you don't set them yourself. So when the data fed to the scrollbar exceeds 10 then LabVIEW automatically adjusts the scrollbar slider width to handle the visualization of the larger data. LabVIEW also takes into consideration the actual width of the scrollbar as well. So if you stretch it out then the slider will resize larger accordingly. If you wanted to make the slider wider, then you need to set the PageSize property to be a certain fraction of DocMax. Since the default is probably 1, which will make the slider super-thin.

Hmm, I'm not seeing this message myself. Try logging out and back in to see if it goes away.

Which notification? Do you mean the "Something went wrong" message? So I think you are mentioning 2 issues. One is the message and the other is the incomplete profile step.

How do you login? Using built-in login or facebook? I'm thinking it's a caching issue maybe.

Wow, those LAVA cats really worked overtime. Looks like the site is back up and working. Let me know if you notice anything strange. Thanks for your patience! I just noticed we now hav a leaderboard. Cool.

If that's real, please add it to OpenGDS, like now!

Automatic error handling is for noobs.

I get that. But thinking about it even more. It seems you would want to have a feature to completely remove an installed Package ?. Otherwise you would have an ever-expanding database of files.

Hey LAVAmaniacs! It's been a while since I poked at the LAVA server. There seems to be a lot cobwebs and dust in the server room. The LAVA software hasn't been updated in a couple years. That's way too long. I'm going to jump in and see what I can do about upgrading the LAVA back-end to the latest and greatest. This will fix many issues. Last time I tried this, it failed and I had to revert back. I didn't plan on it failing and didn't allocate time for getting tech support from Invision. This time I'm planning for the upgrade to fail and then getting Invision support involved. This means the site might be offline for a few days beyond the weekend. Sorry, but it's a small pain we have to go through for long-term stability and security. Don't worry though. This time I have a crack team to help me out:

Well, the idea behind the original LabVIEW Wiki was to create a Wikipedia for LabVIEW. So linking to external content was welcome, using similar rules as Wikipedia uses. Mainly as cross-reference material or at the bottom of a page where further research could be done. Having said that. A page with all the LabVIEW blogs (which we had before) would definitely be ok. However, creating a dedicated sales page, for example, for your new Modbus toolkit would be forbidden. But a page dedicated to how Modbus works and used in LabVIEW is fine. Where then you could create a section on that page linking to all the Modbus toolkits and code available. There's a fine line that needs to be walked. The Wiki needs too have a definite purpose. It's ok if that purpose changes. But if it's just left wide open, then it will serve no purpose and be just another dumping ground on the web.

This is not GPL. JKI figured out a way with VIPM. So it can be done.

So if LabVIEW is not trying to manipulate the linked files (delete, rename, etc) and is just reading or saving them, then symbolic link should be enough. However if LabVIEW tries try to manage these files then it's better to go with hard links. In this context I mean the LabVIEW IDE, not the package manager written in LabVIEW. But I think the two link types might not matter to the package manager written in LabVIEW. Since it will always be working with the installed files in the Application Data folder. All of the "work" on the files would be done there and not under the LabVIEW IDE folders. Some work to unzip the files and some other work to create the links which would be a bunch of Admin-level command line calls. Am I understanding this right? @rolfk As far as the zip changes your making. Explain the use-case of supporting "hard" or "soft" links in the first place. How do you use this in the context of zip?

Using the concept of links. In Windows there are hard links and symbolic links. How does this difference affect the behavior of this proposed solution? Also, creating these links required Admin rights. Of course this seems somewhat expected in the world of installers.

That moderation extension seems like it might work.

Where to start. A wiki here a wiki there, everywhere a wiki. We used to have a section on LAVA which was like a Wiki many many years ago. However, I shut it down. Reasons: Users didn't know it was a Wiki and instead of posting questions to the forum, would create new Wiki pages with their questions. This was a nightmare to moderate. It was setup so that when you created a Wiki page, the discussions for that page, would be linked to dedicated forum threads. Again, more confusion, since it was not a model commonly used elsewhere on the web. The forum\wiki blend was not very intuitive and it made the site hard to "figure out". Nobody cared or understood the wiki. A handful of people used it and never really caught any steam. After that experiment was shut down, I decided to create a separate domain dedicated to the LabVIEW Wiki. It was labviewwiki.org. I still own this domain. I think this was 2009, I don't recall. But anyway, I used the same open-source software that powered wikipedia, mediawiki. Here's the wiki-index page: https://wikiindex.org/LabVIEW_Wiki. Seems like it had around 300 pages. MediaWiki is super powerful, but not intuitive for new editors. I spent most of the time creating templates and documentation describing how to edit pages. I created a lot of the content but there were some others who added unique content like all the LabVIEW ini keys. All the keyboard shortcuts. All the hidden scripting features (before it was mainstream), etc. It was pretty cool. And yes, we had awesome landing pages and getting started pages that I spend hours and hours crafting. I was young and motivated. The problem was that we got struck with a rash of spammers. More like bots. They would go through and create hundreds of pages overnight. In that environment, you need moderators and editors to delete the pages and watch for edits. I was the only moderator and admin. So my plate was full. I ended up locking it down and forced it so that you had to have a login account to edit pages. On top of that, the login's had to be manually approved by me to prevent bot accounts. Of course, a wiki cannot be maintained or augmented by one person. The whole point is to have a community edit the pages. Not sure if Wikia (or MediaWiki) has solved the spamming issue. @The Q, I noticed a lot of the content is scraped from ni.com. Have to be careful about this and copyright claims. One thing I was very careful about with the LabVIEW Wiki I worked on was to create original content as much as possible. Also, what's the point of just duplicating ni.com. That's pointless in my opinion. Google does an excellent job of getting the info you need from multiple sources. But that's my opinion and the community edits should drive that of course. Sounds like the community wants to reboot the Wiki idea like Hollywood reboots comic book heroes. Sure, let's see where this goes. @The Q seems to be enthusiastic about it. Are there others here willing to put the time and effort into building the content? Any volunteers? If there is some real interest, then I can try to resurrect the old Wiki content and domain (not sure if the content it's salvageable, but I can try). Then we can go from there. I don't have time to admin the site but I can hand over the keys to someone that has more time.

VI Shots LLC will be donating an Apple TV 4K 32Gb More info here: https://www.apple.com/apple-tv-4k/

I'll be there this year!! If you want to save money, you can share a room with me. Just ask. Also, come running with me in Austin.

Hey fellow LAVA people. I just turned 50 on April 2nd, and wanted to do something challenging for me, both mentally a physically. I'm running 10K every day for a year and raising money for cancer research. If you want to follow along on my journey, you can subscribe to the 10K365 youtube channel for the latest. Then go on over to 10K365.com and give whatever you can. Thanks, I consider all of you as friends and one of the reasons I love LabVIEW.

Well, I've found a workaround to the above problem in the meantime. But to your question, this cluster doesn't physically exist. This is dynamically generated from various sources. I then pass the variant data into another function that processes it into a specific file format. So it's a means to an end. The data size is simply a factor of a lot of configuration parameters. This is an old app. Probably, if i was to redo it, I would take different approach. But it is, what it is.

After I woke up this morning, and had a coffee, I did some probing and came to the same conclusion. We have a roll-over situation on the U16\I16 combo for the array length math. So digging into the type descriptors doc in the LabVIEW help (which I never thought I would have to do today), it seems that there are two formats (7.x and 8.0). OpenG uses the 7.x format I assume. So is this fixable by updating how OpenG handles type descriptors and making it use the 8.0 format? Or is it more than that?