hooovahh

Attached is the VI performing the DLL calls and I think doing the same work as your original VI, notice there isn't anything in terms of error handling so you may want to check the return type to ensure it has no error.  It should give you the prototypes you need to call this DLL outside of LabVIEW.  Although I've never done this type of thing before, is there some legal notice that should go along with this DLL?  I'd assume you are allowed to distribute it since building an EXE in LabVIEW will include it.
Encrypt Decrypt Demo Using DLL 2014.vi

Yes, a value change event does not necessarily mean a different value than the previous one.  You can use the Value (Sig) property to set a control to the current value and the event is still triggered, same with this.
 
The solution seems like an easy one.  If the old value, is equal to the new value, do nothing.  The old and new values are available in the event that is triggered.

Hm....well I think a continuous read might be the fastest.  Set it up to perform something like N channels N samples, reading continuously at a fast rate, then perform a read, taking in all samples ready to be read.  You will likely get lots of samples because of your fast rate but who cares, just grab the newest for each channel, do calculations, and write single point, or maybe have the write task already open set to a continuous write, and do not regen.
 
The point I'm making, is I suspect that if you have your read task set to a continuous read, then just read how ever many samples are on the buffer, then this might be faster than reading a single point on each channel one at a time, because the task is already running and all that needs to happen is transfer the data.
 
Maybe the write can work the same way but it might be more complicated.  If you already have the task running, maybe performing a continuous write would be faster than multiple single point writes, but regen needs to be off.  Otherwise your output will repeat because this is usually used to do something like continually write a sine wave, you use the write once and it loops back around but, in this case you wouldn't want that.  Sorry I don't have any hardware to test on.

Software design has many questions that need answering, and this is one of them.  I've seen some software written where each dialog in the application was its own separate VI running a while loop in parallel with the other ones.  Each VI and loop had a messaging scheme to show and hide the dialog.  This mean there were something like 10 parallel while loops just handling dialogs.  This goes too far.  I've also seen applications that have one while loop, where DAQ data logging, report generation, sequencing, communication, database control, and UI were all in a single loop.  This didn't go far enough.
 
In the end it is up to you to decide how it should be designed, and personally I don't mind adding parallel loops as long as the functionality and responsibility of the loop is well defined, and encapsulated.  Performance-wise it might become a problem.  An atom is not a powerful PC, and if each loop is doing lots of work in timeout cases you will have a problem eventually.  But if most of the time, most of the loops are truly idle, not polling anything, then I wouldn't worry too much about it.

That's what I thought too, but I do have those special keys and I don't have OpenBinaryLibrary.  So not only did something go wrong, but it went so wrong that some features even more secret than the super secret ones have been partially exposed.
 
It sounds like your code is royally hosed somehow.  Probably some kind of error where the timeout case is no longer valid, and the events are then shifted by one, which caused your value changes to turn into something else they probably shouldn't be.  Hope you have source code control.
 
I'd also bet that a repair install of LabVIEW will fix any new VIs made, but doubt it will fix any VIs saved that were in this broken state.  You're probably going to need to contact NI for any real support.  But thanks for sharing.

Sure but a crosspost helps give some context to those unfamiliar with the history of the issue.

If you want to use an analog out for generating you setup you can.  You'll have other limitations that might get in the way making that difficult.  Like the fact that when a new buffer is put down, you'll either need to stop your task, which will drive the output to 0 while for some time, or you can replace the buffer values but you can't resize the buffer.
 
So say you want to generate a waveform that is a PWM at 100hz and 50% duty cycle.  Using an analog out you can generate a single cycle of this wave and tell it to repeat.  But if you want to change to 50hz and 50% duty cycle you'll need to stop the current task, create the new buffer, put that buffer down, and start the new task.  This will mean that for a few milliseconds your output will be 0v.  
 
A counter output gives you more some features that an analog out can't, and an analog out has some features a counter can't.  Some tasks can use either.  Your 9178 chassis has two BNC connectors on the front that can be used as counters.  And my example was designed and the 9188 which I'm guessing has very similar features.  If you can get my example working, then it shouldn't be too difficult to replace the array of frequency duty cycle pairs with your own and have it work.

Ahh yeah that wasn't clear.  Still doable.  Write each A and B clusters on their own, then iterate over all elements in the Cluster C writing them one at a time in a for loop, then do the reverse for the read.
Write Read Cluster 2.vi

I've posted this before but I can't seem to find where now.  This is a VI that will read the Windows registry and return the development, and run time versions installed, along with the "Current" version, which is usually the last development version opened.
LabVIEW Versions Installed.vi

I'm pretty sure this was reported on the NI forums and the easy fix was the LabVIEW band-aid the always copy.  I tried in 2014 and it also is broken. 

Okay how about this.  Some kind of helper VI that runs in parallel, that monitors the value of the controls, by reference.  If the value does not equal what it did before, it sets the Value Sig property node, which should generate the event like always.  You'll need some way to kill this VI running in parallel of course on shutdown.  And there is a bug that when the control value is changed like normal, the event will be generated twice.  You can look at the time to filter out a duplicate event.
 
Attached is a quick example of what I am describing.
Event Work Around.zip

EDIT:
 
Alright never mind I just made the XNode from scratch.  It supports LabVIEW 2011+.  It supports breaking the wire if the input is not a cluster, it does clusters in clusters, it has the type adaption on the output, and the icon changes color, based on the color of the cluster wired into it.  I also built an EXE using it just to make sure that worked and it does.  All source is included with no passwords.  To see how it works just open the XNode Template.vi.  It will basically just set the cluster size and change the terminal types to what was wired.
Array Of Variant To Cluster XNode.zip

Your google-fu has failed you.  That feature of Quick Drop has been called Super Quick Drop, and on the dark side I had a very similar issue.
 
http://forums.ni.com/t5/LabVIEW/Super-Quick-Drop-Fails-Me/td-p/2833156
 
For me I first suspected DisplayFusion because I use that as a multimonitor program, but it turns out that it was TeamViewer and the QuickConnect feature.
 
For it I suspect it is some software interaction, but might not be TeamViewer.

Okay so I have a working test of what I was talking about with the Pre Build action.  Attached is a project with a VI in it that gets the text of a Formula Node in the development environment.  It also has a string constant that is blank, but before building the EXE it will take the value from the expression node and put it in the string constant.
 
Build the EXE and you'll see that the value of the string constant will change to the value in the expression node.  Not ideal but it can be done with minimal engineering effort, and using all built in tools.
Formula Node Test.zip

Your image doesn't look like it represents the function you are asking for.  I implemented the function the way you described it.  You provide a folder of JPGs and run.  It loads the first picture in the folder.  If there isn't any it prompts you.  Once it has been loaded you use the Next and Previous buttons to go between images.
Cycle Through Images.vi

Do a repair install of LabVEW (or DSC).  Go to Add Remove Programs, choose NI and modify it.  Then a menu will come up with all the NI software installed.  Choose LabVIEW and click repair.  This will reinstall all the files needed to run LabVIEW.  Note that you will need the LabVIEW CD/DVD as a source.

I'm not sure I fully understand what you need.  Your post was a little wordy.  But I think what you want is the "Mouse Down" event on the graph.  This will be generated when a mouse click event happens when the mouse is on the graph.  You can then read the "Button" value and determine which mouse button was used (left, right, middle).  You can then determine if the mouse is on a specific part of the graph and ignore the event or not based on other criteria.
 
EDIT:
 
Okay so I re-read you post and I think you want to know when a plot is clicked on.  Attached is a quick example on how you might be able to do it.  Run it and click on a data point on the white plot and it should stop and tell you what you clicked on.  Note that this only works on the points them selves, and not the line drawn between them but you can modify it to support that.  Also note that if you are within 5% of a point it considers you clicking that point, for some large or small graphs this may need to be changed.
Graph Mouse Click Plot.vi

If you are missing the lvapp.rsc from LabVIEW you likely need to perform a repair on the install of the development environment, or run-time engine (or both).