I haven't been able to work on it for a bit here due to chasing down issues. Suddenly everyone gets new toys at Xmas and start changing things and finding issues that have to be explored, and Bryan had some more extensive issues on an upcoming Pluckers installation that had to be explored, and still may need some more.
I need to get the old Homeworks client side driver updated for a client now as well. I never converted it because there's only one customer using that version of HW and so I'd not have had anyone to test it, but now they've upgrade to 5.x and I need to get that done.
And I'm also just trying to tie off any reported issues so as to get a 5.x followup out that takes care of the known stuff and that adds a few small but very useful improvements.
But I'll get back to Z-Wave next week.
So, in between doing other things, I've got a couple very useful improvements done.
1. I've just about finished a 'find widget' tab for the interface editor. It's a new tab in the right hand tabbed window of the editor pane. It allows you to do some basic but useful widget searches. I'll do a quick video on it when it's done. But you can search by any combination of id, by caption text, by widget type, and by referencing a specific image. The id, text, and image path to look for can all be regular expressions for partial matches and such. So you could find all command buttons that reference an image within the /User/Whatever/ scope, and that kind of thing.
It fills in a list of widgets. You can select one or more of them, and it will select them in the editor. The idea is than you can can then go over there and deal with them. But there is some weirdness in that the editor hot keys can't be active when you are in the search tab because the entry fields and list and such have to process keyboard input. But there's no way to get back over there without clicking in the editor. But that will change the selection. So I need to figure out something there.
2. The remote file selection dialog (where you select images, macros, etc...) now remembers the last path accessed for each file type. If no previous path exists, it will go back to that. That makes it MUCH more convenient for a lot of operations.
(01-05-2018, 08:19 PM)Dean Roddey Wrote: [ -> ]So you could find all command buttons that reference an image within the /User/Whatever/ scope,
Great, been waiting for this - I know I have quite a few of these gremlins hanging out in my templates.
Here's an item for the wish list - In the admin console, let us pop out the interface editor tab or let us choose to close the menus on the right and bottom (or float those menus). Not sure if doable, but I wanted to put the request in.
Yeh, the ability to minimize those panels has been around for a while. It just needs doing.
Nice. Question - in the interface editor, how do I set a border around an area fill on a specific side (not around the entire thing)?
Nevermind - I just used a line. Works just as well.
OK, I have the widget search stuff done, and took care of a number of general things that came up in the process of doing that. The widget search stuff is fairly basic, but a big step up from having none at all.
I'll bang on it a bit more tomorrow and then get a drop up. It has a lot of general fixes that I've been accumulating. Then I need to work on the old Lutron HWs client side driver. Then I can get back to the Z-Wave driver.
So finally figured out Bryan's issue. It was that he'd make changes and do a scale templates, and the changes, after the first time, wouldn't show up in the output. It turns out there is a double slash (//) getting into the template paths in some cases, the list of templates that the scaling process found and needs to scale.
The MS keeps an in-memory cache of accessed files, and the path is the unique key. And it was assume it would be impossible to have the same file get into the cache under different paths. If you got the CQC path wrong, that would result in a wrong file system path and the read or write would fail. But in this case it could happen because Windows ignores double slashes. So no error would occur, it would read the file, but into a different cache entry (the path with the double slashes.)
So, the first time, it would read the file and pick up changes. After that, it was hitting that memory cached version that was never getting updated by file edits because those changes were going into another (correct) cache slot. So, from that point on, he'd never see changes for those files from the scaling process anyway. As long as the file was accessed by its right path you'd see them, but the scaling process was continuing to access it via the double slashed path, so it was seeing the unchanging version.
So I'm putting stuff in place to first make sure that you can't get a double slash into path, and that any that might have gotten stored that way are fixed when the data is next read in. And I need to find out where in the scaling stuff I'm managing to get double slashes into the paths. And I'll put a safety check in the master server to refuse any read/write operation with such a path, so that they can be caught if they manage to still sneak in somehow.
Oy! If it ain't one thing, it's another.
OK, lots of safety checking code done today, not just about the above, but some other stuff while I was in there doing things, so well worth doing all around since it should just make things tighter. And I realized I was missing a good opportunity to coalesce some validation code in a common place where I can apply quite a bit for a lot of code with minimal muss and fuss. Moving things around to take advantage of that was a lot of the work for today.
Even though these changes would make the double slashes benign, I need still to see where they are getting introduced in the scaling code. Somewhere as it's building the paths there's some scenario where it's doubling one of them.
I got some more good fixes in today, and I'm just about done with the Homeworks client side driver, which I keep getting distracted away from by fixes. I'll probably get another drop out tomorrow.