Idea for idea exchange: move/copy file progress info

[billko]

---

@Hooovahh wrote:

---

@billko wrote:

---

---

LabVIEW makes it easy to implement the busy cursor, why not a file progress indicator?

---

Because LabVIEW is supported on multiple operating systems that all deal with setting the cursor through different methods so having a single way to change the mouse cursor that is OS independent is useful.  In the same way that the Read/Write file isn't an OS dependent call.  In my mind the cursor wasn't about convenience to the user, but convenience to the developer. (again I am still a fan of the idea)

---

Ahh, I understand what you are saying.  I consider the busy cursor and the file progress indicator to both be conveniences for the user because they inform the user there is something going on.  You are saying that the busy cursor is a convenience for the developer because it makes it easy to implement.  In this way, "hiding" low level file functions in VIs makes it more convenient for the developer - but a file progress indicator isn't something that would be totally unweildly to make yourself.  Like you could make your own library.

[littlesphaeroid]

Thanks for all the feedback. I particularly like the idea of having a function that can request updates of transfer progress and speed. 

It also seems that there's some agreement that conveniences for the user and for the developer go hand in hand. We love LabVIEW because many features require no programming. Thing of how full-featured graphs and charts are, and how these feautres benefit the developer and user. The march of progress will continue ot flesh out these details.

Based on the feedback I've received, I'll go ahead and add this to the idea exchange!

[rolfk]

Well, you may think that the progress dialog for file operations is a Windows feature, but strictly speaking it is simply a file explorer feature. Some of what used to be Windows file explorer was then moved into the shell shared library shell32.dll, but technically it is not Windows and LabVIEW does not make use of its functionality for any file operation but directly calls into the real Windows kernel API kernel32.dll. Those APIs have absolutely no user interface interaction safe from a few fatal error dialogs.

Should LabVIEW implement a progress dialog? I'm not sure and tend to say that implementing this in a VI library is easy enough to not make this a show stopper at all. I've done it in the past both for file IO and FTP file transfers, and it wasn't that difficult.

The point about cursor icon change that was brought up is a good argument too. To do this without a some direct OS calls (which would be different for every platform LabVIEW runs on) would be absolutely impossible if LabVIEW would not provide those VI interfaces to its internal functions, that it needs anyhow to implement to change the cursor for its own operation.

There is however no reason that you could not write a small VI library to implement a progress dialog functionality on top of the LabVIEW file nodes, and it would work on all LabVIEW platforms the same. If NI had an internal progress functionality in LabVIEW, I would say yes they should expose that possibility to the application, but they don't have that and adding it would make the file IO functions only slower, even for those who don't want a progress dialog in their LabVIEW application. It would impose some asynchonous interface to the progress data that would probably be almost never used since asynchonous operation is for many a pretty hard nut to crack and wrap their mind around.

[Shijie]

I fully agree with you. NI should create two Copy functions, one with progress bar and one without progress bar.