LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Idea for idea exchange: move/copy file progress info

I've got an application to publish test software (multiple large test libraries) over a network, and the large file and size and slow transfer speed begs for a progress bar. 

 

In Windows, file move and copy will produce a progress dialog if the time to complete the operation exceeds a second or two. This behavior can be recreated in LabVIEW by using read/write from binary file and transferring small chunks of the file (see http://forums.ni.com/t5/LabVIEW/Using-Progress-Bar-when-reading-binary-files/m-p/313390#M162287) but this is a bit of reinventingf the wheel, and gets complicated when copying directories.

 

How coudl NI provide an asynchronous update of file transfer speed and progress for the Move and Copy file primitives? Would this be worthy of the idea exchange?

 

 

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 1 of 14
(3,791 Views)

@littlesphaeroid wrote:

Would this be worthy of the idea exchange?

 


In my opinion, no.  However, if you want it, it should be fairly straightforward for you to write it.

 

Bob Schor

0 Kudos
Message 2 of 14
(3,727 Views)

Hi Bob, would you can to elaborate? Why would it not be useful to provide enhanced user interface options for large file transfers as part of LabVIEW?

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 3 of 14
(3,692 Views)

Feel free to propose it, but don't be disappointed when/if it is turned down.  Generally, accepted Ideas are things that benefit lots of LabVIEW Programmers doing general task -- an example would be the Cluster Constant that can "collapse" into its Icon (I've posted an Idea to allow other Constants, such as multi-dimensional Empty Arrays, to similarly "collapse" into its Icon, so far not accepted).

 

Your Idea, while not "bad", seems to me too particular to be considered by NI of sufficient general benefit to LabVIEW code development to be accepted.  But that's just my opinion.

 

Bob Schor

0 Kudos
Message 4 of 14
(3,683 Views)

 

I didn't really mean to ask for an opinion about whether the idea would be accepted, but meant instead to find out if the idea would benefit other users and whether it should be part of what LabVIEW does out of the box.

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 5 of 14
(3,676 Views)

I'm a bit conflicted.  On the one hand I'd probably have used it a few times over the years.  And do in fact have progress bar code for FTP transfers (I had to modify the FTP core VIs to get the information out).  Should LabVIEW nativly provide this functionality?  Or should it be up to the developer?  Maybe the native implementation would be slower to copy files if it had a progress to update, and some developers might not like that.  Having the core code to perform a copy (read/write binary file) and then tracking the amount of data copied/moved and updating a progress is possible today, so you could write a library to handle this and share it with the community (if you do be sure and post it here)

 

That being said NI does have progress bar information on another File I/O operation, which is the TDMS Defragment function.  In the Example Finder there is a function that can enable a progress, and can then be queried.  A similar type of function could be made to enable the progress update of a move/copy.

 

If you make the idea I'll vote for it, but I'm not so sure I really would need it.

0 Kudos
Message 6 of 14
(3,639 Views)

Maybe it's not so useful from a developer standpoint, but I could see it being useful for the user.  Any time you can inform the user of something taking a long time, the better.  Keep the user occupied, they're less likely to break your app.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 14
(3,634 Views)

@billko wrote:

Maybe it's not so useful from a developer standpoint, but I could see it being useful for the user.  


If it's a feature request of the user, then the developer needs to implement it.  It might be easier for the developer to implement if the language had native support for it, but at the end of the day my user doesn't give a hoot what the language supports.  Again I support this idea, but I can see why NI may never implement it.

0 Kudos
Message 8 of 14
(3,631 Views)

@Hooovahh wrote:

@billko wrote:

Maybe it's not so useful from a developer standpoint, but I could see it being useful for the user.  


If it's a feature request of the user, then the developer needs to implement it.  It might be easier for the developer to implement if the language had native support for it, but at the end of the day my user doesn't give a hoot what the language supports.  Again I support this idea, but I can see why NI may never implement it.


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

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 14
(3,610 Views)

@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)

0 Kudos
Message 10 of 14
(3,588 Views)