Jump to content

Michael Aivaliotis

Administrators
 View Profile  See their activity

  • Posts

    6,196

  • Joined

  • Last visited

  • Days Won

    103

 Content Type 

Posts posted by Michael Aivaliotis

  2. Force Pane Size event

    in User Interface

    Posted

    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.

  6. Scrollbar's slider width changes as I acquire data

    in User Interface

    Posted

    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.

    Screen Shot 2018-11-07 at 1.00.56 AM.png

  13. Open Package Building Discussion

    in Application Builder, Installers and code distribution

    Posted

    8 hours ago, ShaunR said:

    That's not my vision and would argue that it would be no better than under vi.lib. I think we both see the value of install but for uninstall you don't want to touch the target packages - just delete or recreate the links.

    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.

    • Popular Post
    • Popular Post

    LAVA Server Maintenance This Weekend (11\03\18)

    in Site News

    Posted

    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:

     

    lava_server_cats.jpg

    • Like 4
    • Thanks 1

  15. LabVIEW Content Landing Page

    in LabVIEW General

    Posted

    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.

    • Like 2

  17. Open Package Building Discussion

    in Application Builder, Installers and code distribution

    Posted · Edited by Michael Aivaliotis

    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?

    • Popular Post
    • Popular Post

    LabVIEW Content Landing Page

    in LabVIEW General

    Posted

    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.

    • Like 3
    • Popular Post
    • Popular Post

    I'm running 10K every day for a year, follow my journey.

    in LAVA Lounge

    Posted

    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.

    • Like 4

  24. Error 116 occurred at Flattened String To Variant in Array of VData to VCluster__ogtk.vi

    in OpenG General Discussions

    Posted

    10 minutes ago, drjdpowell said:

    It should be possible to update the OpenG VI, but why are you working with such a monster as a 997-element cluster in the first place?

    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.

  25. Error 116 occurred at Flattened String To Variant in Array of VData to VCluster__ogtk.vi

    in OpenG General Discussions

    Posted

    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?

×
×
  • Create New...

Important Information

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

  I accept