Jump to content

Michael Aivaliotis

Administrators
  • Posts

    6,217
  • Joined

  • Last visited

  • Days Won

    120

Posts posted by Michael Aivaliotis

  1. The problem is that people don't use anchor text in their posts. Instead of using friendly text they post the whole thing. The above URL should be posted like this. Notice that I used the word "this" as my anchor, NOT the entire URL.

    Let me spare you the the thought process. YES, I AM blaming all the LAVA forum members for this problem and NOT the RSS generator.

    PS. I'll look into it...

  2. QUOTE (Yen @ Mar 28 2008, 03:06 AM)

    Another idea that I thought about now is modifying the OpenG VI so that I do the header analysis part of the variant parsing before building the EXE and save it as a constant, but that has its own disadvantages and I'm not sure how much improvement it will get me.

    I'm not convinced that you have a problem. You say that it used to work and now it doesn't. Why? You say you upgraded to the latest variant tools and it worked. Then after a while it didn't.

    Could you post the data structure so we can try it out and benchmark it?

  3. QUOTE (PaulG. @ Mar 21 2008, 11:35 AM)

    It only took a minute to set it up and it could not be any easier to use. I'm just a little skeptical of anything that's "free".

    Don't be skeptical, just accept the fact that at some point the company will have to figure out a monetization model. However it's possible to use advertizing to fund the service and keep it free. It depends. We all use tons of Google tools in our daily lives and it's still free for me. Even if Google charges me at some point, i've had so many years of using a great product that I won't regret it.

  4. QUOTE

    we could store the destination directory as "..\..\..\builds". Now if you move the project to C:\temp, what should happen?

    Well, it seems that you already have implemented a backup plan for this because if the path doesn't exist you revert to the fixed path right? So do the same. Ideally, the build should fail with a descriptive error because I've had many time where I have built something only to scratch my head when the output is missing. Then I realize thet the builder created the entire hierarchy of paths to the build out put in the WRONG location. However, the scenario you describe is a very rare case. Most developers I know work with a source folder NOT a single project file. Moving the project file is bad. Typicaly you would move your project folder. In my example, this is the "subfolder".

    The main thing is that NI's definition of relative falls outside the typical understanding. The destination is NOT relative to the project file regardless of how you spin it. It's a non-standard handling. The other option is to allow the user to enter a relative path themselves in the form "..\..\..\builds" and the problem is solved. No sweat of NI's back.

  5. QUOTE (gmart @ Mar 19 2008, 06:15 AM)

    I haven't got a change to look more into this, but the default destination directory is not the directory you listed. It is something like "D:\_Projects\Experiments\subfolder\buildpathissues\source\builds\mycode\My Application". So the directory in your example may not fall into the definition of "relative" from the algorithm that calculates this. I'll look more into this when I get a free moment.

    Aaaarg! Definition of "relative"? Response from support:

    QUOTE

    Thank you for contacting National Instruments. The relative path seems to

    work correctly when the default is used for the Destination Directory. I

    have tested out several scenarios and it seems that the relative path is

    used as long as the Destination Directory points to the location of the

    LabVIEW Project or a sub-directory within that folder. I have also found

    that it works when it points to a folder that is next to the folder

    containing the project. I'm going research this issue further and get back

    to you with more information. In the mean time, could you test out the

    following destination directories?

    1) D:\_Projects\Experiments\subfolder\buildpathissues\

    2) D:\_Projects\Experiments\subfolder\buildpathissues\source

    3) D:\_Projects\Experiments\subfolder\buildpathissues\source\mycode

    Please let me know if you see relative paths when copying these Source

    Distributions to another location on your hard drive. Thanks!

    Just to remind y'all, the project file is located under the "mycode" folder.

    So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

  6. QUOTE (gmart @ Mar 19 2008, 06:15 AM)

    I haven't got a change to look more into this, but the default destination directory is not the directory you listed. It is something like "D:\_Projects\Experiments\subfolder\buildpathissues\source\builds\mycode\My Application". So the directory in your example may not fall into the definition of "relative" from the algorithm that calculates this. I'll look more into this when I get a free moment.

    Aaaarg! Definition of "relative"? Response from support:

    QUOTE

    Thank you for contacting National Instruments. The relative path seems to

    work correctly when the default is used for the Destination Directory. I

    have tested out several scenarios and it seems that the relative path is

    used as long as the Destination Directory points to the location of the

    LabVIEW Project or a sub-directory within that folder. I have also found

    that it works when it points to a folder that is next to the folder

    containing the project. I'm going research this issue further and get back

    to you with more information. In the mean time, could you test out the

    following destination directories?

    1) D:\_Projects\Experiments\subfolder\buildpathissues\

    2) D:\_Projects\Experiments\subfolder\buildpathissues\source

    3) D:\_Projects\Experiments\subfolder\buildpathissues\source\mycode

    Please let me know if you see relative paths when copying these Source

    Distributions to another location on your hard drive. Thanks!

    Just to remind y'all, the project file is located under the "mycode" folder.

    So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

  7. QUOTE (Aristos Queue @ Mar 19 2008, 02:35 PM)

    Wasn't meant to be. I was trying to be helpful. He wanted a way to instantiate templates without the project window. That's the only way I know to do it. The other possible method is open the .vit and then do Save As:Copy, but that method doesn't duplicate all the subVIs that may be linked templates that also need to be instantiated.

    Come to think of it, it's a bit strange to me to even have a .vit in the palettes. I guess it would be useful if you build a lot of templates to be able to drop templated subVI calls, but that doesn't seem to be common.

    A representation of the VI is staring right at you in the palettes and you are helpless but to stare right back at it. Such a powerful tool as the palettes and so underutilized.

    One option (which really only works if the template is not calling other template VI's) is to right click on the icon and select Open VI. Then you can save it as a normal VI. As I mentioned, not practical if the template calls other template VI's.

  8. Thanks for the feedback Yen. Even though the color scheme is what it is, I just want to point out that the NI Forums have pretty much the same scheme and a white background. Of course this doesn't mean anything I just want to mention it as a comparison because you hang out there as well. I assume you don't like the NI Forums colors too? I'm just asking out of curiosity.

  9. QUOTE (Eugen Graf @ Mar 17 2008, 09:48 AM)

    So it appears you started the discussion to introduce a multi-language tutorial site\blog and now it appears it's just going to be English forums. That's fine, just don't try to deceive people. We're all working here to simplify things and unite the LabVIEW community as much as possible. It's hard enough trying to survive under the NI juggernaut (who now is creating their own Wiki, hey why not get our customers to build our site, heck they're solving their own problems on our forums anyway, and... let's not contribute to an existing Wiki like let's say oh i don't know, LAVA, because it's not "made here"). I don't think it's productive to create yet another LabVIEW forum. That's one of the reasons ExpressionFlow and LAVA have teamed up. We felt it was for the good of the LabVIEW community as a whole.

    Of course, as always... It's a free world. Well, most of it anyway.

×
×
  • Create New...

Important Information

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