Cursor Drag Error on Intensity Graph

[boochbrain]

Ok, so I found another interesting issue while programming today. This one took a while to debug and isolate the source of the problem.

 

So, the story goes like this. I was having this error in one of my projects, where I would drag a cursor on an intensity graph using my mouse, but every so often I would lose control of the cursor and it would drop wherever my mouse was hovering. This was abnormal function, because if you keep your mouse pressed down while dragging, you should be able to move a cursor around indefinitely.

 

I figured out that I could remedy the issue by disabling a section of code where I called the "write to spreadsheet file.vi" in the File I/O Pallette. After some debugging, I figured out that if the file path inputting to this VI was inside of a LabView project folder that was auto-populating, then the error was happening. When I turned off  the auto-populating setting forthe folder, the issue was gone.

 

So now I've figured out the source of this issue, but I don't understand why this relationship would occur. What does saving a file have to do with my cursors in an intensity graph. Shouldn't they be running on completely different threads?

 

Any help on this matter would be greatly appreciated.

 

test_cursor_moving.vi

[todd]

I don't use auto-populate, and I have not had the need to put data files in the project.

Just curious - why do you put data files in the project?

[boochbrain]

I usually have a Saved Data folder within my project. It is used to store spreadsheet files or any user data captured by the application.

 

I realize now that there is no need for this to be auto-populating, because I never need to call any VIs from this folder, and thus the files within the folder don't need to be a part of the project. Any time I use a sub-VI to write to this folder, I will provide the exact path in the code, so the project doesn't need to have the file linked.

 

I thought the folder itself should be part of the project, because when it comes time to build, you could add it as a destination folder for the exe. However, after testing, I think you can still do this without it being a part of the project.

 

Thanks Todd, for making me realize that.

 

I still want to know why this all relates to cursor dragging. Why would these two seemingly seperate functions relate?

[Darin]

I still want to know why this all relates to cursor dragging. Why would these two seemingly seperate functions relate?

 

Almost anytime that LV wants thread safety it uses the UI thread.  This includes operations like opening VI references.  Some operation in the auto-population is grabbing the UI thread, probably the first time you pause for a few msec.

[boochbrain]

What does "thread safety" mean? And where can I find more information about how LabView handles threads?

[Darin]

Thread safe code has no possibility for race conditions.  If a piece of memory can be accessed from multiple threads, then some form of synchronization and locking must be employed to allow one operation to complete before the next one starts.  It is ok if the order of multiple operations is not deterministic, as long as each operation is atomic.  Let's say LV is trying to load the same VI in two threads.  They could both look and see that the VI is not in memory, and then they both load it, and you have two copies floating around.  If they are forced to be sequential, it does not matter if thread 1 or thread 2 wins and does the loading, what matters is the second thread will see that the VI is in memory and not reload it.

 

The hard way to achieve thread safety is with mutexs, concurrency checks, and other locks, and means you had better catch all possibilities.

 

The easy way to achieve thread safety is to be single-threaded.  For this reason, all code which requires thread safety gets pushed into a single thread, which happens to be the UI thread.

 

Why the UI thread?, well LV was multithreading when multithreading wasn't cool.  This involved rolling their own cooperative multitasking which means a task grabs the thread for a while, and then gives it up to another task in the pool (often putting itself back in the pool to work again later).  A 'rude' thread won't give it up so easily, but most times it appears that parallel tasks are being done.  This framework is still present in the UI thread, it can be single threaded when needed, and cooperative to emulate multitasking.  Thread safe code grabs the UI thread and does not let go until it is done.

 

Someday, there may be additional special threads to separate some tasks from the UI.  It is true that it both has come a long way, and that it has a long way to go.