Ton Plomp

Just a 'hack' idea: make the window it's own exe with the icon1, then call this exe from the main (icon2).

Felix

No i'm not really looking for a hack, I just want change the icon of one dialog window.

Here's the code I currently have which doesn't work:

It seems like the LoadImage works properly, but when I run it I can see that alt-tab the default labview icon is removed but not replace by the icon I want., but I cannot get it back.

SetWindowIcon.vi (LabVIEW 2009), you should be able to run the code wit any bitmap file.

Ton

Does anybody know if it's possible to change the icon (taskbar/titlebar) of a singel window?

I'm looking for a solution that might be windows only! Win32 is accepted as well.

Ton

By the way, Wolfram, congratulations on being only the 6th user I've ever heard of using the Rendezvous VIs in the 10 years I've been working on LabVIEW.

It's being used in the Code Capture Tool.

Ton

Every version of LabVIEW going back at least to 3.0 has had a bug fix release. There's nothing new about the 2009 one except that we called it a service pack. It's curious that you mention 8.6's stability. By the CAR count, 2009 was more stable than 8.6. But these sorts of things are subjective to the parts of LabVIEW that affect you daily, so different customers may have experiences that vary greatly from the objective count.

In case you haven't heard, LV 2011 is going to be largely a stability release. The entire LV team, acting on requests from customers, is going to pull back on features, focusing on bugs, performance and integration between existing features. There will be very little that is new in LV 2011, but we think customers will want it nonetheless.

I hope the NI LabVIEW sales department didn't went to the Business of Software 2009 conference and saw this (great) speech by Joel Spolsky.

The following still is at 25:31 and I quote:

The correlation between features and sales is

Ton

I added a Hardware idea to the NI idea exchange:

Add LabVIEW events based on hardware

Ton

Did it get fixed somehow?

This one is really weird - I think something has gone haywire with the IDE, contemplating reinstall.

A repair fixed it.

What really weird was that only on e install of VIPM did that, and that error logs on disc had some Unicode issues as well.

Never really studied it though.

Ton

This is what the Application Splash Screen looks like:

I had this for VIPM (but only for VIPM).

Ton

Has anyone been working on an Oauth library for LabVIEW, I browsed the specs and how-to and it doesn't seem that complicated.

Oauth is becoming more important now that Twitter is limiting (or shutting down?) the basic authentication for API calls.

So I was thinking about this, but couldn't find anything on Oauth and LabVIEW.

Any experiences.

Ton

I have a program that runs a number of tests automatically. It displays some information about all of the tests "queued" and highlights the row of the test currently executing in a multi-column listbox. There may be 50-60 of these tests listed in rows of the listbox but the listbox only displays maybe 10 or 12 rows at a time (which means the user has to use the scroll bars at some point to see the currently active test). Is there a way to make sure that the test currently being executed is always centered within the listbox so the user does not have to use to scoll bar to find the highlighted row?

A little mathematics will help you on this, you can get the total number of visible rows (12), and you know your current row number (say 55), the you should programatically (how do you spell that?) set the top.row to 49.

Ton

I found the code for this experiment again:

SubPanels.zip

Ton

I can't say I've run into this particular problem, yet I'm fairly certain I've distributed reuse code using community scoped methods. It could be that I friended specific vis rather than an entire library. ...

Could you describe that a little bit broader? I don't think you can select a specific VI as a friend.

Stepping back a bit and taking a broader view I think your deployment model is flawed. You're deploying the Api module first, then developing the extended Api (xApi) module as an addon against it. Even if you could define friends by name the addon developer would have to use your predefined name for the addon to work. That's not really addon-ish behavior. If the functions in Api and xApi are closely related they should be deployed together in a single module. Use virtual folders and sub palettes to segregate the xApi functions.

I did not say my system was perfect, when (yes, when not if ) NI decides make friends addressable by name, I would opt for a system with wildcards, so I could deploy a system of add-ons.

I would not say that xApi is deployd against xAPI, it is build on the API.

One of the benefits of a modular reuse library is that you can declare dependencies and be assured that the base library is always installed.

If they are different enough to warrant two separate deployment modules you might be able to achieve what you're after by restructuring your libraries. Create a project file that contains three libraries: Api.lvlib, xApi.lvlib, and Common.lvlib. Take all the community vis from Api and put them in Common. Make Api and xApi friends of Common. When you create builds for Api and xApi, the modules will each carry their own copy of Common, so to avoid cross linking you'll have to give the library unique names during the build.

I will explain a little broader what my goal is.

I built a public API (only lvlibs, no classes) that is a nice wrapper around a command line tool, I would like to make this libary public and share it with the community, anyone could build upon this library it's own tools. I have an advanced GUI in mind that uses this wrapper and would like to make some money out of this tool, and being the developer of the public API I have some deeper knowledge about hidden VIs, so I would like to give me the power to use these VIs, off-course I could export the VIs to the client tool, but IMHO is any doubling of code a NoNo.

I have run into a strange side effect of friends with paths that's not so nice:

-API.lvlib has declared xAPIt.lvlib and xAPI.lvlib as friends, xAPIt.lvlib is the name of my lvlib during development (t stands for temporary), xAPIt.lvlib is located in the development path, and xAPI.lvlib is located in user.lib

-Now I try to build xAPI.lvlib from source xAPIt.lvlib, during the build fase I get an error from the LabVIEW compiler, stating that a library of that name is allready in memory.

Which means that declaring a friend will cause LabVIEW to load it in memory... (xAPIt.lvlib called API.lvlib which refers to xAPI.lvlib).

That sounds really bad and support (IMO) that friends should not have paths.

I don't understand how linking by name instead of by path makes a friend more or less able to alter data. Can you explain?

I haven't reallys stepped into LVClasses, so rethinking what I said sounds silly indeed. Sorry.

Ton

If I go this route I just remove the legend and create a 2D table with the correct info. Aligning something with the graph-legend is something I gave up on a long time ago.

Ton

The title sounds philosophical, and the question is kinda philosophical...

When you declare a library as a friend you need to provide a path to that library. I was expecting this path was only used to get the name of the library, however the LVLIB file (and I assume LVCLASS as well) stores the path and the name.

I thougth this was a bit strange. Here's why I would like to refer to friends by name and not by path:

I am writing an API, and an extended API (an add-on module), for convenience I would like to open up some functions that are private to API to the add-on. So I declare these functions as 'Community scope' and declare my add-on module as a friend. Everything works fine... In development.

Now I make a build of my API which installs the API into user.lib (hey and maybe sets a password on the library).

Then I start developing on my add-on module, which is broken since it cannot get to the private methods of the API, what happens is that LabVIEW is issuing a Cross-link warning dialog. Stating that it expects the add-on module on a different relative path to the API then it actually is. If I resolve this the API lvlib file will be changed. What if I update my API and replace it with a new version, then I have to re-connect (and alter) the API again. (I am not even talking about moving the add-on into user.lib)

This wouldn't have happened when I was allowed to define friends by name (here comes a very weak analogy to real life: 'I don't care about the cell-phone number of my friends, just about there names').

I can understand how changing the linking to 'by name' may compromise the validity of classes (a friend might alter data), however a friend of a lvlib cannot alter data (I rule out a functional global inside a lvlib, that wouldn't make sense and should be class) of that library.

Any thoughts/comments?

Ton

Hi John,

officially you should post it at OpenG.org, in the builder feature request forum. However LAVA works as well. I have been working on and off on builder, but it's a very complex program, if you want to help write code please join us!

If you want to help, PM me and Jim Kring in conversation. That way we can discuss the current state and roadmap.

Ton

I'm going to start a Real Time (Crio) project and it's been a while since I've been there. Last time was 5 years ago.

It's an old controller and I am wondering if a how a State Machine will perform on that platform?

Or any other recommandations?

Ton

And maybe the most impressing one, it could crash the VI and LabVIEW and that might cause a VI-file corruption....

I know NI is working hard to prevent those things to happen, but once in a while (once a year) I see this happening to a colleague who refuses to use an event structure...

Just make you don't just hide the toolbar, also disable the abort button (other wise ctrl-. will still work).

Ton

Here's a little startup:

StructToVariant.vi

This VI will try to read a Typedef and return it's contents as a cluster with the right elements.

Together with the Variant to Control (with which I would like to integrate this) you can convert a typedef-string into a (typedef) control file).

I have tested the converter with the following typedef string:

typedef struct {  uint32 header_sz;  uint32 width;  uint32 height;  uint16 nplanes;  uint16 bitspp;  uint32 compress_type;  uint32 bmp_bytesz;  uint32 hres;  uint32 vres;  uint32 ncolors;  char nimpcolors;} bmp_dib_v3_header_t;

and the following Enum struct:

typedef enum {  BI_RGB = 0,  BI_RLE8 =3,  BI_RLE4,  BI_BITFIELDS,  BI_JPEG,  BI_PNG,} bmp_compression_method_t;

It supports sparse Enum's for instance.

It however does not support nested structs (reference to another), that might be something to add.

If you make any changes I would like to see them here.

But variants suck, so you don't want to do any of that anyways. Stupid variants

As said earlier, have you looked at the Variant To Control tool-VI?

Ton

I added these two to a new WIKI page called 'Application Builder', please expand this page with your knowledge on the Application Builder.

Ton

Look at these KB articles:

LVMerge and LVCompare. One thing to note that these tools are part of the Professional LabVIEW Suite.

If you have an integrated SCC you can use the Compare function directly from within LabVIEW.

Ton

I did not see a property for min or max. I did find value, which should be spelled in the plural to eliminate confusion, and used that property in a for loop to changed the out of limit values dynamically.

Here's a snippet what Crossrulz and Scott meant:

Ton

Several times I've written code in C++ to make a custom stringgrid where the columns were checkboxes for T/F entry, and other columns were strings and yet other columns were dropdown list boxes of numerical values while another one was of enumerated types. I sure wish that the multicolmn list box had the ability to insert various types objects in addition to strings for each column in the list box! As it stands now I am usually making a cluster of controls (type def'd) where each cluster is represents a column in a 2D table of objects where. The gymnastics of finding the index to the control in the cluster controls[] property and then using this index into all the other clusters to process a line entry into the 2D table is quite interesting if one is basing actions on mouse events on an element of the table.

Hi sydney,

if you want to get leverage on this I would advise the following:

-Post here some code showing all the issues you have to go through to get a nice UI like this.

-Post an Idea to the NI Idea Exchange.

-Post here a link to your Idea, to get additional support (kudos) for your idea.

Ton

Long shot, what happens if you make bar and baz a 2-d array?

It might be that the orientation is off.

Ton

All - thank you for your suggestions. I ended up using the suggested method with the window appearance. I had tried this initially and the method didn't work well for me. I neglected to mention in my original posting that I wanted to open multiple instances of this sub-VI as the program went through a list of conditions. This method will just recycle the previously opened window.

Never the less, I've modified my program to append information in this sub-VI such that all information is retained when the window is recycled.

Thanks again for the assistance!

David

Well, if you are going for multiple windows, you should set the VI to be reeentrant (don't share clones) and set the windows properties to what I suggested earlier.

That should work as well.

Ton

HTTP(s) client VIs.

Ton