(07-02-2018, 07:52 PM)IVB Wrote: Do you think that networking issue would be the reason a 2ndary server would show fields in black, but the MS shows it in red?

(07-02-2018, 06:15 PM)bigdude Wrote: I updated to 5.2.914 when you updated the ISY driver.  That guy works great, but I've been having another serious problem now.  My triggered events work great for a few days then they stop working.  If I cycle the CQC app shell they'll start working again. I can watch the Event Triggers Monitor and the events show up with the correct source and useract. For example, when I arm my alarm system, the "SecurityArmed" User Triggered Event is supposed to fire.  And it does for a few days then stops even though the events keep registering on the monitor.  In fact, all triggered events stop working. Scheduled events work fine. I've checked that none of the triggered events are in a "Paused" state even though they really shouldn't have become that way.

A week ago, I updated to 5.2.919 but the problem persists.  I'll try 5.2.923 today but I don't see anything in your version notes that makes me believe anything has changed related to triggers.

At the same time as my 914 update, in addition to switching to the ISY driver, I also started pausing and unpausing some of my triggered and scheduled events in my actions (sometimes in rapid sequence with only a 1 second pause) using EventSrv:auseTrigEv(xxxx, True) and EventSrv:auseSchEv(xxxx, True). Could such a pause/unpause mechanism have confused something (even though it's only a small subset of events being paused/unpaused)?  I can get around that if you think that's the problem by using the variables driver and some logic. I could also force the CQC app shell to cycle once daily but that's annoying because things like my alarm system start beeping.

How do I figure out where things went weird?

(07-02-2018, 09:15 PM)Dean Roddey Wrote:

(07-02-2018, 07:52 PM)IVB Wrote: Do you think that networking issue would be the reason a 2ndary server would show fields in black, but the MS shows it in red?

It would be the most likely reason. If you done click one of them on each machine, what do they show as driver status?

On the secondary driver, open the CQC Command Prompt, and do the usual:

CQCNetTest > nt.txt

and post the nt.txt file. That will show us what is going on from the secondary in terms of connectivity.

• The attribute editor, when the ... is clicked for multi-line text attributes, was not enabling the handling of CRs in our standard multi-line input dialog. So you couldn't get new lines into the text, it would just invoke the default button when you hit enter.
  
• The interface engine's update to use the new publish/subscribe method was checking to see if the changed widget had a parent container and calling the publish call on the parent. But it needs to also see if the changed widget itself is the container and call it on itself if so, else we don't get changes to the template itself reported, such as drag resizing and whatnot.
  
• There were a number of issues with the template itself redrawing properly in the editor window when resized by mouse or keyboard or attribute editor. It wouldn't redraw the selection handles correctly. It wouldn't adjust the window size in all cases to contains the new template size and so forth.
  
• If the mouse was over the template while you adjusted the size via Ctrl-arrow keys in the attribute editor, the status bar would not update to reflect the size change because sizes (as opposed to areas that child widgets have) changes were not being published as widget changes.
  
• The new Integra NR676 support didn't include Video1 in the valid video sources.
  
• Forgot to update the About dialog's copyright date.
  
• If you resized a widget via the attribute editor using the ctrl-arrows or ctrl-shift-arrows, it wouldn't correctly update the display so that the selection handles wouldn't get updated.
  
• When I stopped using accelerator keys in the attribute editor in the previous drop (they don't work in dialog boxes), Alt-arrow keys stopped working for adjusting the position of widgets in the attribute editor window, because apparently any alt shifted key is reported via WM_SYSKEYDOWN instead of WM_KEYDOWN. So I need to handle both of those in my core dispatching framework.
  
• And now using any alt-shifted key combos in a window without a menu or accelerator causes a system ding sound. There is no way to get around this that really works. So, the attribute editor now uses Ctrl-arrows as before for changing the size of a size or area, and Ctrl-Shift-arrows for changing the origin. Oh well...
  
• The Omni client side driver's documentation was not updated to reflect the 5.x UI changes.