Jump to content

Mellroth

Members
  • Posts

    602
  • Joined

  • Last visited

  • Days Won

    16

Posts posted by Mellroth

  1. QUOTE (Shaun Hayward @ Sep 25 2008, 04:55 PM)

    ...but has anyone come up with a simple method for avoiding having to do the whole unset read-only thing after every commit?...

    As crelf is saying, I think you are better off leaving this as it is. Also remember to have LabVIEW treat read only files as locked!

    If you still feel that you'd like to automatically unlock files, you can probably do so, by adding post-hook scripts in TSVN settings, or by editing the config file in C:\Documents And Settings\<user>\Application Data\Subversion\ directly.

    Maybe the no-unlock property in the miscellany section fits your needs (keeping you files locked even after commit).

    /J

  2. QUOTE (PaulG. @ Sep 25 2008, 03:23 PM)

    ...but your called VI needs to be under the "always included"...

    I don't think it has to be set as always included, if it being used by static VI reference as indicated in the screenshot. But I would recommend that you retrieve the VI name from the static VI reference instead of having a constant specifying the name.

    Here is a little trick I used in the past to force a FP to be included in a build, without having to explicitly set this in the build specifications;

    1. Open VI properties

    2. goto "Window Appearance" , customize

    3. uncheck the "Allow user to close window" option

    I don't remember if I used this in LabVIEW 8.5, as I recall it is enough to have VIs included as static VI references, but I might be wrong.

    /J

  3. QUOTE (PJM_labview @ Sep 24 2008, 07:17 PM)

    ...forcing LV to not reuse the buffer by creating another wire branch (see image below) is the only workaround that I have found...

    I added a "always copy" primitive right after the Get Image property node, and this also solved the issue.

    /J

  4. QUOTE (PJM_labview @ Sep 24 2008, 07:21 PM)

    I had a look at the other thread, very nice little VI :thumbup: Thanks!

    I first tried to go for a built in method to access the bmp's, but as I realized it could not be done, I also decided to get the images programmatically.

    So far I haven't got the time to do it, and now you spoil all my fun :shifty:

    /J

  5. QUOTE (alfa @ Sep 24 2008, 10:04 AM)

    All of you will have a NDE.

    You don't have to attend a conference to know that :rolleyes:

    Hopefully I will only have one NDE, that will take place years from now, and it will be the last thing I do...

    /J

  6. QUOTE (alfa @ Sep 23 2008, 09:12 AM)

    Can you please explain why you feel that LabVIEW programmers should attend a Near Death Conference? (You know you are in a LabVIEW forum, right?)

    I agree that I sometimes feel more dead than alive, but I cannot blame LabVIEW for this. More likely it is due to late nights and early mornings.

    /J

    PS. Do you count being hunted by half-naked women as a Near Death experience? If so, will there be any special sessions regarding this, perhaps with some demonstrations?

  7. QUOTE (orko @ Sep 23 2008, 03:25 AM)

    Is this not the case?

    Thanks Orko,

    I was probably a bit unclear in my first post.

    Built in symbols are accessible for usage, but in my case I'd like to be able to retrieve the actual pictures being used, regardless if it is a custom symbol or a built in symbol.

    From the link you posted;

    QUOTE

    You can use the Custom Item Symbols:Get Symbol and Custom Item Symbols:Get Symbol Array methods only to retrieve custom symbols. If you use these methods with symbols of indexes 1 through 40, these methods return images only for any custom symbols that overwrite the built-in defaults.

    The question is whether there is a way around this to actually get the pictures representing the built in symbols?

    /J

  8. QUOTE (Shaun Hayward @ Sep 19 2008, 11:43 PM)

    ...although we have decided that the ability to a customers earlier project to form the basis of a new project is too valuable to have 1 repo per project. What do you do?

    I would go for one repository per project (or closely related projects, e.g. per customer), using svn:externals to include revisioned parts from other projects/repositories.

    By having one repository per project, each project can set the layout exactly as they need. Thus making the layout within each repository consistent.

    I also feel more safe, in terms of access control, if the customer projects are separated from other customers as well as our internal developments.

    /J

  9. QUOTE (alfa @ Sep 19 2008, 09:41 AM)

    ...the SRI is sending half naked women after me in the church…follow me everywhere...

    OK, they are not completely nude, but how can you complain about this deal :thumbup:

    /J

  10. QUOTE (jlokanis @ Sep 18 2008, 11:46 PM)

    ... I think there is a bug in the code that manages refnums...

    Have you tried to use named Queues? Just naming the queues after the caller VI plus some additional numbering should be enough.

    If memory is corrupted in shared clones, maybe named queues are better protected.

    /J

  11. QUOTE (alfa @ Sep 15 2008, 08:57 AM)

    QUOTE (alfa @ Sep 18 2008, 09:27 AM)

    Darwin didn't understand the Evolution.

    To understand the Evolution read my book: Who am I?

    Here we go again, some "GURU" telling you what to believe just to make money... :nono:

    I actually did some research about your statement of 98% of all people being at animal level.

    It seems that at least 98% of the messages in this thread are below LAVA standards (including this one :blink: ).

    To be honest I think we are very close to 100%, and it must be due to that the original post are leading us the wrong way... or put in another way; that 0.5% of the posters are introducing 99.5% of all low level posts (my numbers might be a bit off, but who cares, its the kind of science presented in this thread)

    /J

  12. QUOTE (DavLog @ Sep 17 2008, 04:54 PM)

    ...I have just started to learn to use Labview...

    Hi Dave,

    if you want more help, you should be more precise about what you want to do.

    It is also a good idea to first show some effort, just to increase the probability to get a good answer.

    When uploading pictures please don't use bmp's, as they become too large (use PNG instead).

    /J

  13. QUOTE (crelf @ Sep 10 2008, 04:50 PM)

    If you're a professional LabVIEW programmer (not a casual LabVIEW user), then I strongly encourage you to get involved in the http://digital.ni.com/beta' target="_blank">LabVIEW Software Engineering Tools beta. I think what NI's cooking up over there are some of the most important improvements for professional LabVIEW programmers that I've seen in years.

    I couldn't agree more.

    /J

  14. I like the project, as it allows me to include non-LV files in the LabVIEW environment and also because of the abstraction, but...

    * One of the strengths with LabVIEW is that it is graphical, and previously we used to group all top-level VIs in a VI-Tree for easy access.

    In the project I can pretty much do the same thing, but then the Icon (graphical) view is lost, and so are some of the benefits of the graphical layout.

    I would therefore like to see the LabVIEW project turn more graphical, e.g. display VIs and CTLs with icons, at least as an option (as we have in the pallettes).

    * I also think the development distribution needs some work. We have had a lots of trouble distributing FPGA code (for some reason the FPGA VIs and the bit-files were omitted from the distribution) as well as code containing VIs that were not executable (e.g. VI-Trees).

    * I would like to see an installer for RT applications as well as windows apps. Currently we can create installers for windows, but no deployer/installer for the RT applications. When you have multiple targets for your RT application it would really help if an installer for RT was available.

    /J

×
×
  • Create New...

Important Information

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