mwebster

Yep, I was thinking exactly that after I got it working, no need to wrap single statements.... Thanks for the links!

I think you're right. I was expecting it behave like RELEASE. ROLLBACK TO doesn't commit, you're still inside the SAVEPOINT transaction.

LabVIEW 2020. Example.vi I removed the savepoint hookups in the Modify UUT Info.vi to make the error come out explicitly. If you hook those up, it fails silent. I "fixed" it by removing the savepoint hookups in the Save UUT Info.vi so it just does a BEGIN IMMEDIATE/ROLLBACK. SQLite Transaction failure example.zip

I originally had it wrapped in a Begin/Commit as well but removed them to see if that was part of the problem. Same issue there, the in-memory copy had the update, but not saved to file. Thanks for the syntax check though, I didn't see an UPDATE in the example code, so wasn't completely sure about that. Okay, I found it. I was attempting an Insert originally and, if that failed, I was trying an Update. So, for whatever reason, the Insert transaction wasn't getting closed out properly on error. For a named transaction, when there's an error, it is doing SAVEPOINT X / ROLLBACK TO X, but this isn't closing the transaction. I didn't get an error on this until I tried an unnamed transaction for the update, which attempt to do BEGIN IMMEDIATE / (COMMIT or ROLLBACK depending on error state). When the update function tried to do BEGIN IMMEDIATE, the API threw an error saying you couldn't begin a transaction without closing the previous one. I then went back to the Insert and removed the names from that (so it does BEGIN IMMEDIATE / ROLLBACK when it hits an error) and then the subsequent UPDATE call works as intended. Not sure why ROLLBACK TO X didn't close the transaction, but that was the root cause. Thanks again for the help.... Mike

I've got a weird one that I can't seem to find the answer for. When I try to update a row in an existing table, it seems to work OK, subsequent queries show the updated data is there. However, after I close the connection and reopen it, the old data is still there. Is there some in-memory copy that's not getting flushed out with UPDATE? Insert's work fine... This is just a two-field table, SN primary unique string key and PN string. Creating them saves them almost instantly after finalize (checking with external viewer). Update doesn't save them where external viewer can see it, but doing a query in LabVIEW does see it until I restart the connection, as mentioned before. I've also tried it without binding using format into string where I just have the SQLite statement say UPDATE UUT SET PN='10029-201' WHERE SN=123 but the same thing happens. Am I missing something simple here?

Second for Sorensen's. I've used their DLM600's on several projects using GPIB. Drivers on driver network have been fine for me. I'm not sure how fast you can sample back their IV though. Whenever I've needed that information faster than human monitor speed, I've tended to put in a couple of signal conditioners and a shunt so I can get DAQ sampled / aligned input. Oh, and only 1U high and half rack wide so you can pile in several in a small footprint. I also really like Acopian gold box power supplies. The programmable ones have been stable and linear enough in my experience that they can run open loop after calibrating (i.e. 1V AO = 5V supply, 10V AO = 80V supply, calculate scale and offset and you're off to the races). Again, you'd need DAQ hardware and signal conditioning to sample back voltage and current.

Yeah, the tutorials were great. Maybe add an overview VI with one of each of the various widgets you've implemented so far? I still don't really know what a DoubleSpinBox or FontComboBox is ... Nothing in particular, I was thinking of how to extend the chart functionality with a right-click menu popup or something. Just thinking about what could be done. The chart you have looks like maybe a wrapper for QChart without all of the properties exposed? I also did a little playing around with the stylesheet property input and got some cool background gradient effects on the indicators. Neat stuff. It would be cool if we could access the full QML markup (like drop this QML markup string into this container layer) to do things like control animations, but I don't know how you'd go about accessing those declared controls programatically back in LabVIEW. Mike

It was the one you actually mentioned in your documentation with the dynamic GUI composition, where selecting Tab Widget, Splitter, or MDI Area causes LabVIEW to freeze when transitioning back to edit mode. I do agree that the learning curve would be easier to absorb into a large scale project. I guess my problem is I work on too many medium scale (1 or 2 developer) projects. The intimidating thing to me was the thought of using this for the entirety of the project, I'm much more comfortable with using a piece of it to implement something LabVIEW can't do on its own. I was wondering though, can you get any events from the widgets besides the signals they emit (valueChanged, sliderPressed)? i.e. mouseover, mouse down with modifier keys, etc?

You're right, and I don't do entire projects with those either. You raise a good point though. I may find a way to use this like I do with the occasional ActiveX/.NET stuff, as a component of a project. I could see using it for a sort of dynamic data viewer (Select 1 to n channels from a group performing active acquisition, add and bind indicators / graphs to a container and poof).

So let me say at the outset, this is very impressive. It allows for dynamic runtime creation of well-behaved controls and indicators that resize beautifully and have tons of customization options (lots of work has obviously gone into Qt Widgets). I really like the way you can link objects together solely through the Qt framework or through events or through callbacks. I hope I can find an excuse to use it. However, I have absolutely no vision of how to use this on anything outside the smallest of projects. The overhead required to do manual, programmatic layout removes one of Labview's biggest advantages ((relatively) quick GUI development). And it's like the worst of both worlds, the complexity of text based GUI design with the interface of doing it through Labview. It reminds me of how when I do anything beyond the simplest math, I reach for the equation node. Oh, even more, it reminds me of the Labview TestStand OI. That thing makes me cross-eyed every time I delve down into it. So many callbacks and hooks. I'm sure given the time I could replicate what I'm normally doing in a standard GUI, but the learning curve seems very daunting. Other practical observations: Obviously the Labview crashing thing needs to be figured out. I really wish Labview played better with external code, I ran into a hard crash to desktop just last month trying to use an external C# .NET library if everything wasn't cleaned up just right (accidentally hit abort button from muscle memory? bye-bye labview). We should be able to rename event wires. I dove into this a bit on the interwebs and apparently it isn't possible at runtime (you can cast it to a different, fixed name with a typecast, but not to a dynamic name). I can see this being a real issue if you decide to use a bunch of events in your program. I guess we could always cast them just before event registration, just a little painful. You speak of possibly having a GUI editor in the far future. Something like the QT Creator IDE frontend that figures out how to use VI scripting to create the equivalent Labview calls? Unfortunately I feel like I would probably need something at that level before diving in headfirst. All of that said, I do plan to keep an eye on this. Some of the capabilities of QT are really cool looking, especially in regards to themes, graphs, and accelerated 3d visualizations. Best regards, Mike

Trying out examples: Lib path is hardcoded instead of relative. Must install to c:\LQWidgets or modify lib path VI. I will try to provide more feedback when I have a chance to play with this more, but I wanted to point this out ASAP so others don't give up on trying this out prematurely. I also want to say that from a just toe-wet perspective, I'm very impressed by the organization, documentation, and depth of the examples so far. Edit: And, obviously, you document this in the README file. Who reads README's?

If you're looking for a particular file with a known filename, I cannot recommend enough voidtools.com Everything search tool. I seriously don't know how I got along without it. It indexes every file on fixed disk locations (takes a minute or so on first startup) and after that, it winnows through the file list as fast as you can type. Works with wildcards as well. I have mine running on startup and bound to Win+A. It's really great for finding duplicate files, projects, different DLL versions. It doesn't look inside the file at all, but for many, many needs I haven't found anything else that can touch it.

I just came across this last week. There's some nice stuff in there. Definitely some pieces that I may wind up using and extending for future projects. I especially liked the mouse wheel graph zoom function you wrote, very neat and modular. I had done roughly the same with modkeys as a proof of concept when they introduced mousewheel events, but it wasn't nearly as self-contained. Mike

What we have settled on doing is moving non-native libraries into our project directory (which is under source code control). I've just worked on too many legacy projects with missing dependencies. I had one recently where the original dev company was out of business and the company that wrote the library (for their hardware) was out of business. I wound up having to redo a communication module to a different piece of hardware over about 40 hours which should have been less than 2 to reinstall the source and compile for a new machine. More business for me, I guess, but there have been enough other occasions where I, or some other colleague, has cost me hours of dependency hunting that I find it's more than worth it to keep a project as encapsulated and portable as possible. And we don't even do that much multi-developer work, I imagine it would be even more important then. I would love to have a way to have a "project.lib" directory to support palette menus out of local directories, but at the end of the day it's not a great loss since I'm using quickdrop 95% of the time anyway. I tried using VM's a couple of years ago, especially for older legacy code from LV6 & 7, but the performance wound up getting so abysmal. Maybe it was my setup, but we had sprung for VMWare and had CPU's with the VT feature and had tons of ROM, but it was still just appallingly slow. This was before I had an SSD, so maybe that would have helped, maybe I'll revisit it if any of our old legacy projects wake back up soon. Oh, and OS licensing. My reading on it at the time lead me to believe that if you weren't a Microsoft Certified Partner (who get unlimited installs based on their license) you were technically supposed to pay for an OS license for each separate VM. It looks like that might have changed with Windows 10 "Software Assurance" licensing, but I haven't done any real research on that ... Mike

I was looking for 2013 SP1 and the google link took me to the "latest release" page which looks like it's just been updated with 2014. Looking through the release notes and the only great! feature I saw was the Reviewing and Updating Type Definition Instances. This one always frustrated me to no end. Now, it makes efforts to map automatically update default typedefs and if it can't decide how to do it, it puts the instance in an "unresolved" state and prompts you to manually update it. I really didn't see anything else of much note. Probably the lightest new feature bump I can ever recall... Mike