Jump to content

hooovahh

Moderators
  • Posts

    3,360
  • Joined

  • Last visited

  • Days Won

    268

Everything posted by hooovahh

  1. They probably learned a lot on that project, learning is satisfying if you enjoy the subject. This subject is legos so I probably wouldn't have a feeling of being satisfied either. Some would say developing in a "fisher price" programming language can't be particularly satisfying either. It does seem like this could make a nice marketing tool, for both Lego and Rolls Royce.
  2. Interesting that they can sell the "Student Edition" to non-students, or rather people who are not enrolled in a higher learning facility. In the comments someone links to the NI FAQ on the difference between versions, and it seems like the difference is there is no support from NI, and you have water marks on the VIs which are removed when ran in a professional version.
  3. That's one way of doing it. If I was going to make my own installer, I would build an EXE with LabVIEW 7.1 or older, so that the runtime engine can be included. I would put my real EXE (built with modern LabVIEW) in a subfolder along with any support files (possibly the required runtime engine as well). Then zip all that and convert it to an EXE that runs my 7.1 EXE after getting extracted to a temp folder. That way there is only one EXE to the user, that they run, extracts and runs a LabVIEW EXE and runs without any runtime engines installed, and from there can install my application or other components. Of course coding in 7.1 isn't impossible, but there are some functions that are taken for granted that I may have to code my self which were not available then. Also I'll essentially be including two run time engines. The 7.1 runtime engine was around 12MB zipped up so it won't add alot of space but still is extra code that won't be used after the install. I've never done this approach, because it is re-inventing the wheel and supporting a tool seems like a pain, for very little added benefit.
  4. I'm not quite sure what you're asking, so I'll answer the question I think you are asking, because I know the answer to that question. In the past I've used Inno Setup to make software installers. Part of the installer has the ability to have standard installs, custom, minimal, and settings for what to do based on the users selection, as well as installation directory and what to do during an uninstall. I've used this in the past to install several NI components at once. Lets say I had LabVIEW Run-Time engine, the TDMS for Excel Add on, and maybe any number of other NI installers, in my build. Then each of these can be a checkbox during the install, which will simply run the setup.exe for each component, with what ever silent switches that are needed. I've also used ISTool which is a piece of software that helps make Inno Setup installers. I don't believe there is much for UI customization, I've always used the plain one. One thing I would be interested in is how JKI does it for VIPM. I'm guessing what they do is very customized and probably not something worth sharing.
  5. This works perfectly thank you.
  6. Sorry I didn't give more detail, I didn't want to inundate anyone with too much information, especially if the answer was a simple property node. I'm doing something similar to Ben's Docking code. http://forums.ni.com...cending#M351512 Here VIs get pulled out (sorta) and become floating windows. In this case the VI always is open, it just may be in its own window, or in the subpanel. What crelf said.
  7. This returns true when in a subpanel. EDIT: Also I started looking at the properties/methods available to a subpanel and I was surprised at how few there are. I couldn't even find one to tell me what VI was loaded into the subpanel. Is there really no way to know what is in a subpanel. DOUBLE EDIT: Apparently it is in 2012 beta. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-subpanel-property-VI-Ref/idi-p/1214481
  8. I think I know the answer to this, but is there a way to know if a VI is loaded into a subpanel from the VI that may or may not be in the subpanel? So say I have 5 VIs running, each of them can be loaded one at a time into a single subpanel in a 6th VI which is running. Is there a way to know from any of the 5 running VIs, if they are currently loaded into the subpanel? At the moment I am keeping track of which VI is in the subpanel from the 6th VI which the subpanel is in and this works fine, I just didn't know if there was a better solution. I have also noticed that the property Front Panel >> Title Bar Visible will be false if a VI is in a subpanel, so this could be used as long as the VI has the Window Has Title Bar set to true in the VI properties. This solution won't work for me, because there is the occasion where the VI will have no title bar, but will be outside the subpanel.
  9. Wow this takes me back. So I forgot about some code I did when I was first learning LabVIEW. I had a java program that made an analog clock, so I wanted to recreate it in LabVIEW as a test of my newly found skills. Here is the result. I'm a little ashamed of my code written back then, but it was a learning experience. I'll probably look back on the code I'm producing now in several years and think the same thing. Edit: Man I need to update my site some time.
  10. The question was about Multitouch. For LabVIEW to support multitouch, first windows needs to support it. By default if you installed two mice on your PC, you still would only have one pointer and both mice will control the same pointer. As mentioned by Yair a touch screen is just a mouse so to support multitouch you really need to support multi-mice. A quick search found several 3rd party programs to have multiple mice in Windows, but I've never tried any.
  11. That's what I was going to suggest. At one point I was trying to interface with 7-zip through the command line and I believe it too supports gzip compression.
  12. I haven't tested it in anything other than in a development environment, but I believe it will work in RTE as long as the DAQ Assistant VIs are installed. The DAQ Assistant VIs actually call a NI DLL called mxwlvapi.dll, this is what actually does the heavy lifting and I assume this is installed with DAQmx. So theoretically you could create an installer, which has the added installer of DAQmx and this should still work, that is assuming you get the path to the Assistant VIs correctly. I believe there is a registry read that can be performed to help find this. Possibly something like %National Instruments Folder%\MAX\Assistants\DAQ Assistant\common\supportFiles As for how I did it...well, the forums have been discussing very grey topics lately, and one of them is block diagram passwords, and how they have been defeated. So out of my curiosity I started looking into all the VIs that were locked in VI.lib to see if I could find anything useful. I couldn't find much, most of VI.lib that has a password is simply a dll call. AQ has mentioned recently that most of the passworded VIs have been unpassworded to help share with the community and that is apparent here. So I searched my whole National Instruments folder and found these llbs named expressVIsXX.llb with different versions for all versions of LabVIEW. By opening up the daqmxNewItem.vit and daqmxEditItem.vit you can see that it has a control that gets casted to a DAQmxName object, and has code for Channels, Tasks, and Scales. So you can actually use this same code to Create/Edit a Virtual Channel or Task. I'm not sure why this information isn't a knowledge base somewhere other then the fact that NI may choose to change how these VIs work in the future. AQ has mentioned recently the dangers of using code from a password protected block diagram, but I don't believe this falls into that category, because I didn't use any code from a passworded VI, I'm just calling it, and I needed to know the type of input it wanted for a control. Looking at the BD helped me understand what was needed. In any case NI can still choose to change this functionality in the next version of LabVIEW if they choose.
  13. Looks like you put in a lot of effort into this. One thing I noticed is the list of existing scales show all scales, even ones that are not appropriate for the current tab. So if I have a linear scale, but am on the Map Ranges tab, my linear scale shows up in the list, and trying to edit it doesn't work. Why not only populate the drop down with the scales for that type? Also is there a reason you are doing this all manually instead of using the DAQ Assistant? Attached is a quick VI I made to edit or create a scale. You may need to update the path constant on the block diagram to point to your DAQ Assistant because the path is set currently to a 64-bit Windows, running LabVIEW 2011. Add Edit Scale.vi
  14. I'm very interested in this. I don't want to cause you any work getting an extensive list, but is there an easy way to know what information can be read without loading the VI and all of its dependencies? Edit: I may have found my answer is it the "Loads the block diagram into memory" remark or note, on the property/invoke node?
  15. I've yet to use this feature but on my next new project I planned on not including compiled code. I'd like to hear other users sound off on any issues like these, so I know to avoid it for another version or two. I also wouldn't mind hearing people that have used this feature and have had no noticeable issues.
  16. Some times I wish there were a more open file format for LabVIEW. I'm not looking to write my own IDE, but to be able to open the vi and determine what kind of objects are in it, or what labels there are without having to open it in a development environment would be nice. Lets say I want to do some documentation generation on a folder of VIs. Right now I can read the icon, and VI description without needing to start LabVIEW by analyzing the bytes in a hex editor. But what if I want to get the connector pane information? Like what terminals labels are and their data types? Or what if I use Requirements Gateway and I want to find all labels on the block diagram that start with "Covers: ". Looking at the VI file structure I have not been able to find free labels or text. Here are the things I have been able to pull out of the VI file structure by analyzing the hex bytes: Main/Internal VI version, LVSR Main/Internal version, flag bits, if a VI is protected, the Window Title, the Help Path, the Help Tag, the VI Description, a 24-bit image of the icon, and a 1-bit image of the icon. I think I can also determine if a VI is re-entrant, and the Revision History if I spent some time. I thought about releasing my findings on how to pull out this information from a hex dump of a VI in the hopes someone will be able to get more information, and possibly pull out free label text. If anyone is interested I can try to put some time into cleaning it up a bit and releasing it. I mostly stopped trying to figure out the VI file structure because most of what I want to do can be done with LabVIEW Scripting. I just think that it could be done faster by reading the VI file.
  17. So I did develop a fix of sorts. I basically re-created the functionality of the Plot Legend so that I could do the things I wanted. Like don't allow the value of the vertical scrollbar to be greater than the number of plots, and allowing me to change the value of the scrollbar programatically. The problem with re-creating the Plot Legend is there is a ton of functionality in it. Changing plot color, plot type, line width, line size, bar plots, filling to other plots, interpolation, point style, scales, exporting data, and a few others. What I did was re-create the functionality I used the most which was a very small subset. In the end I wasn't satisfied with the results and all the extra code involved so I reverted back to the normal Plot Legend just leaving a few known bugs with how the graph functions.
  18. Just let him have his fun. It lets him feel like a leet haxor. But seriously NI doesn't appear to have any thing to hide in those VIs, as demonstrated by this here.
  19. There's a few things I don't like about the graph controls, and this will just add to my list. I'm going to guess that the reason I have such difficult times with graph controls behaving the way I want, is because they are more advanced controls than a simple string, or numeric, and alot of functionality is actually built into the control, and the behavior I expect may not be the behavior that NI intended when they came out with them. Sure they've added features over the years, with different Property/Invoke nodes, but I still feel like they are complicated and would need NI to invest alot of time to get them to function in a way that is more useful. The functionality in that plot list section of the graph control is very lacking when compared to an array with a vertical scroll bar, and maybe that is the real problem I have with it and exposing more functions for it would probably make me a little happier.
  20. This discussion reminds me of an another Windows API I have yet to use but have wanted to. I saw that there is an API for controlling the progress of an application, through the taskbar (not sure if there is a name for it). http://sine.ni.com/nips/cds/view/p/lang/en/nid/210184 Very neat stuff, but like I said I haven't found a good place to use it yet.
  21. I'm glad I could hover over that and get the file name, I would not have guessed that was supposed to be a girl.
  22. Yeah I was worried you would make that decision, but I understand. As I'm sure you already know many of us LabVIEW nerds are passionate about LabVIEW and get excited about new features, and ways to make our lives easier. I hope that you understand our curious nature, just as I understand why you won't be posting prototypes in the future.
  23. I of course remembered that VI. I was also informed of the instability of that function and the dangers it has. The point of this post is to warn you to stay away from the Randomize 1D Array function he posted, and to not use any functions you maybe able to pull out of it. As much as I love to dig into NI R&D features, this is one that is truly not ready for prime time. NI wants to have an official feature for native polymorphicism, but the methods shown in that VI are not the way to go. (remember I don't work for NI and I maybe mistaken) Discussion of VI protection is allowed (my understanding at least), but the integrity of Lava could be compromised if users came for the sole reason of cracking a VI. Please be cautious around this topic and consult the Forum Guidelines if you are unsure about a topic, or PM a Admin/Moderator.
×
×
  • Create New...

Important Information

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