Jump to content

daal

Members
  • Posts

    36
  • Joined

  • Last visited

Posts posted by daal

  1. I am curious how others have solved the problem of holding a class of hte same type in its private data. For instance, a window class that needs other windows in its private data. I know how to do it; I would just like to see if we can have a discussion on what people have found to be the best method for handling this and why. 

     

    You obviously can't have a by ref class in the "more generally accepted sense" of a DVR inside the class's private data. This still results in recursive loading a compile time error. I have seen storing the aggregated object in a variant, or creating a DVR of the object's type and storing it in the private data of a class. Are there any potential benefits or drawbacks to each? Any other methods you have found to work well?

     

    To resolve this problem, I cast the DVR into a U32. So in your private data of your class you will have only a U32 so not anymore recursive loading. To access your data you will need to recast the U32 to DVR. 

     

    post-223-0-63301700-1390495816.jpg

    • Like 1
  2. [cross-post]

    Hello, I didn't get any reply to my question, I hope i can get someone opinion here

    We use a custom icon editor for many years now and it help a lot to be more productive. Since the introduction of the New NI Icon Editor we continue to use our custom IE but we use the New IE either for API vi with graphics. To do so we need to rename the lv_icon.vi that ship by NI to lv_icon_NI.vi and we called it dynamicaly from our IE. But now the New NI Icon editor is built in .lvlibp and we cannot rename it because it is built. We tried to build NI IE with the source code by renaming lv_icon.vi and conbine it with our IE but this way we can't call the NI IE from our IE. This technique have a side effect to break some tools (NI LVOOP wizard, JGCODE Tools) that call the NI IE with the API.

    Some one know how to get a custom IE that can call the NI IE without breaking other tools?

    Dany

  3. QUOTE(AdamRofer @ Apr 2 2007, 03:57 PM)

    What happens when you drag the .vim from explorer onto a Block Diagram?

    Nothing happens. The VIM doesn't appear on the block diagram.

  4. QUOTE(AdamRofer @ Apr 2 2007, 03:24 PM)

    I'm not sure how far back this goes (probably as far back as the Macroizer thing exists), but this VI appears to run in one instance. Apparently you can have an automatic "macroization" of any VI you want.

    (This was tested in LabVIEW 8.20)

    Step one: take a VI "xx.vi", rename it "xx.vim"

    Step two: drag it onto the block diagram

    Now this VI is a subVI, but note you cannot double click on it to enter the VI itself. I imagine that all the other problems that plague External Nodes in general exist here also, which might be why this behavior is not advertised. You can still access the VI through the VI Heirarchy, although if you copy the VI around the Block Diagram then you might not see it listed as a subVI of that VI (?!?!). I'm sure a lot more "interesting" results can be found...I really don't know what purpose this could have, but then again the locked VI might have some more stuff in it than just this.

    Weird stuff.

    Just a note to get this working, you need to enable external node with "ExternalNodesEnabled=True" in Labview.ini

    And in my case it doesn't work with drag and drop from explorer, I need to use "Select a VI" from the palette

    Dany

  5. QUOTE(Aitor Solar @ Feb 28 2007, 05:10 AM)

    Good work. But I think the abilities' public names not always match the internal names. For example, the documentation talks about a BuildMenu, BuildMenu2 and BuildMenu3 abilities, but internally we have a BuildPopup (whose documentation seems what is defined as "BuildMenu" in the doc), BuildMenu (whose documentation seems what is defined as "BuildMenu2" in the doc) and BuildMenu3 (this one 's correct). And a "BuildMenu2" ability in an XNode gives an ability-not-recognized error.

    I suspect NI renamed the abilities for the LV8.2 project manager (and hence their name in the documentation) but internally they retain the LV8 name. Pretty chaotic for us :-(

    By the way, I have observed the XNode Manager gives an error whenever you add an ability with an absolute path ("relative path?" unchecked). When the application tries to add the VI to the XNode library, it returns a 56003 error ("Adding this item would cause a conflict with an item already in memory"). Strange.

    Saludos,

    Aitor

    P.S.: XNode Manager 1.4 for CR is on its way.

    Thank you Aitor for the update, now it represent the real world of xnodes :thumbup:

  6. Here are the rules:

    1) Create an XNode (not an External Node) that implements the following code, in order to get the default value of anything:

    post-17-1170288652.png?width=400

    2) License your VI under the BSD license.

    First one to complete this challenge will get a pitcher of their favorite beer at Gingerman, this year at NI Week (and possibly have thier VI included in the OpenG Toolkit).

    Cheers,

    -Jim

    Hi, there is my xnode. Finally it's an easy one, you don't have to do any scripting to get the default data. :thumbup:

    Download File:post-223-1170317628.llb

    have a nice day

    Dany

  7. Hi Dany,

    in my opinion a user who knows how to execute an executable from the file browser knows how to run an executable in another way. Or are you disabling the windows key, ctrl-alt-del, ctrl-esc? Might it be possible to create a user account with almost no rights just to run your program? Maybe you can use the .net browser and run that one as a low-righted user?

    Ton

    I used a simple stategy to lock the user from executing other executable. I start my app at startup and I kill explorer.exe and for the operator account I restrict the acces to taskmgr.exe to be executed. That way you can't execute any other EXE and only if you don't have any File Dialog used in your App.

    Dany

×
×
  • Create New...

Important Information

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