Getting Started Dialog Window

[Francois Normandin]

Hi everybody,

I'd like to make some modifications to my Getting Started Window Screen.

I read AQ's topic about Christina's blog Eye on VIs for editing XML file to do just that. However, I'd like to change the ratio of lvproj vs VIs in the Open section.

Since I always code using projects, I'd like to get rid of the VIs & CTLs. I think "GetRecentlyUsedFiles.vi" is the VI that does that trick, but it's password-protected :ninja: . It is set to output the links of the two most recent lvproj and the rest are VIs & CTLs. How can I change it? I don't know the connector pane configuration, so I can't guess what I would need to replace this VI with. At the moment, that would be a shot in the dark. Anyway it's part of a lvlib, so I doubt I could replace it with my own without causing some corruption... Any comments?

[Aristos Queue]

The attached VI is saved in 8.5.1 (which means it will load into 8.5 just fine).

The VI is still password locked, but I've added a new input to the conpane.

Download File:post-5877-1213284663.vi

[PJM_labview]

I think you should be able to create your own.

Here is how I would do it:

- backup the original Getting start code

- Close LV

- Rename GetRecentlyUsedFiles.vi to something like GetRecentlyUsedFilesOriginal.vi

- Open LV and OUTSIDE the project environement (don't open the lvliv) create you own GetRecentlyUsedFiles.vi (see connector pane image below) that call the GetRecentlyUsedFilesOriginal.vi. Save it where the other one was located.

- Close this VI

- Open the getting start window lvlib and relink the new one GetRecentlyUsedFiles.vi to the lvlib after LV complain that it is not part of it.

That should be it.

There might be some variation to this that might work better, but this is a starting point.

PJM

Edit: So much for this, AQ solution is of course a lot easier.

[Francois Normandin]

Thanks AQ! Works like a charm. :thumbup:

Follow-up for the benefit of others: This VI is called by "GetItemInfo.vi" which is unprotected. Therefore, that's where you want to change the default value (2) to whichever you'd like...

EDIT: Thanks PJM. I kind of found out too late that I was able to see the connector pane simply by dropping the VI on a block diagram :headbang: ! but I didn't have the code for getting the most recent projects list. I'm sure it's in itself not too hard to find the right folder or registry entry to get it... But as you say, AQ's solution is much simpler.

thanks all.

[Ton Plomp]

There is a private method returning the most recent used files and projects (seperatly):

Ton

[Francois Normandin]

QUOTE (tcplomp @ Jun 13 2008, 01:35 AM)

There is a private method returning the most recent used files and projects (seperatly):

http://lavag.org/old_files/monthly_06_2008/post-2399-1213335308.png' target="_blank">

Ton

Hi Ton,

Private VI scripting? That's why this VI was password-protected...

[Ton Plomp]

QUOTE (normandinf @ Jun 13 2008, 02:08 PM)

Hi Ton,

Private VI scripting? That's why this VI was password-protected...

I wonder why these items are password-protected?

I can see no reason, to make these methods only available to LabVIEW R&D.

Could someone of NI clarify this?

On a usability note: I think this method should be a read-only property.

Ton

[Aristos Queue]

QUOTE (tcplomp @ Jun 16 2008, 05:50 AM)

I wonder why these items are password-protected?

I can see no reason, to make these methods only available to LabVIEW R&D.

Could someone of NI clarify this?

a) These items serve no purpose outside of the LV editor (i.e. they have no value to a user writing his own programs in LV). That's the first thing that recommends them for being private.

b) The API for these items had some dispute about it. We may decide that we want to change the implementation of these properties/methods in the future LV versions. Making these private means we do not have to support any mutation of existing VIs that load in that future version. We keep a list of which of our VIs use those properties/methods, and we don't bother trying to programmatically mutate other VIs on the off chance they use these properties/methods.

c) It doesn't fall in the category of items that we want to have AEs provide support for.

These three reasons apply to the particular properties in question. There's a fourth reason that things become private and that is that it opens some sort of door that, if used incorrectly, can destabilize LV itself. That's not the case with the particular properties we're discussing today.

If enough reasons apply to a given property, it becomes private. It's the personal judgement call of the individual LV developer who creates the property/method.

[Ton Plomp]

QUOTE (Aristos Queue @ Jun 16 2008, 03:43 PM)

a) These items serve no purpose outside of the LV editor (i.e. they have no value to a user writing his own programs in LV). That's the first thing that recommends them for being private.

The other points make sense, this one a little bit less.

LabVIEW is an IDE, so it makes sense to write tools that make the life of LabVIEW programmers easier. This is IMHO not an NI exclusive field of products. Some of the private options and methods are so valuable that opening them will be very very nice.

There are quite some properties that aren't available in the Runtime Engine so why not just a little bit more?

Ton

[Francois Normandin]

QUOTE (tcplomp @ Jun 13 2008, 01:35 AM)

There is a private method returning the most recent used files and projects (seperatly):

http://lavag.org/old_files/monthly_06_2008/post-2399-1213335308.png' target="_blank">

Ton

I recently opened my LabVIEW.ini file and found these two keys:

[LabVIEW]

RecentFiles.projectPathList=

RecentFiles.pathList=

Are the private methods just calls of Configuration Files VIs? Or does it take the info from registry or some other place?

[LAVA 1.0 Content]

QUOTE (normandinf @ Jul 14 2008, 10:17 PM)

I recently opened my LabVIEW.ini file and found these two keys:

[LabVIEW]

RecentFiles.projectPathList=

RecentFiles.pathList=

Are the private methods just calls of Configuration Files VIs? Or does it take the info from registry or some other place?

I think they will read the INI file

Ton

[Francois Normandin]

QUOTE (Ton @ Jul 18 2008, 06:33 AM)

I think they will read the INI file

Ton

Sure enough... I just tested it. Why do I ask questions that are so easy to check for myself?

I must be a big mouth ...