Official 3.1 Beta Thread

[jkish]

Mostly without issues, but ran into the following:

1) I had drivers with monikers that began with numbers and that isn't allowed anymore. This should be noted as a breaking change.

2) I converted my overlay blanking to the SetTimeout() / OnTimeout() which is now allowed in regular templates. After an initial timeout, something seemed to be bringing my screensaver out of screensaver mode at the same interval as my timeout. The documentation didn't explicitly say anything (that I noticed) about resetting the timeout once you receive one. I added another SetTimeout() call at the end of my OnTimeout() code and that seemed to fix the problem. I have not investigated further, but it seems that something weird might be going on there. I am using Inactivity based timeouts.

3) In my Squeeze Album template, I converted to the new web image widgets from web widgets. The images display fine that I've tried so far and it seems faster than with the old web widgets as I expected. However, the images that I have are dynamic and the widget won't let you get by without specifying a valid image URL. I didn't have one so I just put a dummy one in to get by the checks. When I looked in the logs, I could see that the widget was trying and failing to load my fake image url each time.

I set 'Initially Invisible' thinking that the widget might not try to load the image if that was set, but that didn't work.

The widget won't take file:// as the protocol so I can't point to a fixed image on my machine. That would be a real nice thing to add to the widget so you could load images dynamically from the file system without importing them - really should be a must have.

Bottom line is that the web widgets need a way to ignore the URL field for times when it is going to be set dynamically. Otherwise, the load/display is slower than it should be. Maybe allow the URL to be blank and warn like when the action is empty when you go to save the widget. If the URL is blank, don't load anything.

[Dean Roddey]

OK, I'll change it to allow the initial to be black. I didn't intend it to be otherwise. I just added validation and just forgot to check first whether it's empty and not doing the check.

I'm not exactly sure what the issues is in #2. Can you explain that a little more?

[jkish]

OK, I'll change it to allow the initial to be black. I didn't intend it to be otherwise. I just added validation and just forgot to check first whether it's empty and not doing the check.

I'm not exactly sure what the issues is in #2. Can you explain that a little more?

When I set up the SetTimeout / OnTimeout to do inactivity based template blanking, I first just put an initial SetTimeout(300, True) in the OnLoad of my main template. My screensaver kicks in at 2 minutes of inactivty. I was noticing that as the system ran, my display was coming out of screensaver mode at what seemed like 5 minute intervals even though I wasn't doing anything. The screensaver would kick back in after 2 minutes, but would go away again after 5 minutes of just sitting there.

Not sure what was really causing the behavior, but it seemed like it had something to do with the timeout. I put another SetTimeout(300, True) at the end of the OnTimeout action and haven't seen the problem since.

[Dean Roddey]

It will continue to re-run after the indicated amount of inactivity (where it's on invoked action is counted as activity.) Whose blanker are you using? Ours or some other one? The action running will try to bring focus to the IV, and that might trigger some other screen saver to see that as a reason to go away.

[jkish]

It will continue to re-run after the indicated amount of inactivity (where it's on invoked action is counted as activity.) Whose blanker are you using? Ours or some other one? The action running will try to bring focus to the IV, and that might trigger some other screen saver to see that as a reason to go away.

I'm using a screensaver that connects to Flickr to display photos - that can't be done with the built in blanker.

Which action will cause the IV to get the focus? The OnTimeout()?

If so, I don't like that behavior.

But, I don't see the screensaver interrupted when I put another SetTimeout() at the end of the OnTimeout().

[Dean Roddey]

Up until recently all actions in the IV were driven by a human. Sometimes those might invoke other programs which would take the focus off of the IV, so it always tries to take back the focus at the end of the action, just in case. It's theoretically possible that's causing the screen saver to go away, I dunno.

Try just putting some TTS in the timer instead and then put up the screen saver by hand. If it's related, it'll happen at the time that hte TTS says the action is running and you'll know for sure.

[Dean Roddey]

Version 3.0.19 is posted. One change that was made was to remove from the CQC service configuration any indication that is dependent on other services. It's not really directly dependent. The reason those were added was because, back when drivers couldn't be re-initialized if they failed the first time, that was hopefully to push CQC's startup towards the end of the boot processes. So hopefully everything was up and running by then.

But drivers now will continue to try to initialize, so if there's some fundamental system capability not up and running it's not fatal. And it may be preventing the service from starting on Windows 7 (where those services it says it depends on may not even exist, at least not by those names anymore.)

So I removed them. If anything it should let CQC be up and running sooner in the boot process, without any ill effects. But of course we are a complex system inside a complex system, so just be aware of this change. I can't think of any real differences in how the system would start up and how anyone could have gotten themselves dependent in any way that would be affected. But one never knows, so keep an eye out.

[jkish]

I played with the Album template a little more and discovered that all is not well with the web image widgets. Some of them do not display anything and I see the following in the log file for each one that doesn't display:

11/15 20:08:52-automation2, CQCIntfView, CQCWebImgDLThread_Thread116
{
CIDLib, CIDLib_KeyedHashSet.hpp.1120, Failed/Not Ready, Error: 774/0/0
The TKeyedHashSet<TElem,TKey,TKeyOps> cursor is not pointing to a valid node of its collection
}

It is always the same images that won't display and there are quite a few of them. The same images that won't display in the web image widget will still display in a regular web widget.

[Dean Roddey]

OK, I'll see if I can figure what's ailing it.

[VidaBox LLC]

Normally, things are rock solid in CQC land but I have been having a lot of issues with Interface editor crashing on me (with much frustration as I lose my work). I'm on .17 BETA. Basically, sometimes when I double click the background of the template to bring up the attributes window, IV crashes on me with the following error pop-up:

http://www.vidabox.com/Forum%20Linked%20Files/8590%20-%203.1%20Beta%20thread/ID_error.jpg

I never get to the attributes window. ID crashes out completely and I have to restart it.

In the logs there is one line that states: "Could not allocate memory buffer. Size = 16777216"

[Dean Roddey]

OK, something is going on there, because someone else was having a completely unrelated problem that was effectively due to the the same thing. Is it creating an .ErrorInf file? Obviously some bug has creeped in with some recent change. Do you see the memory usage of the designer running up really quicky or anything like that?

[beelzerob]

I've recently had issues with the Interface Viewer dying via one of those "sorry 'bout that" error boxes (maybe 2 times in the past 2 weeks...which is a lot compared to normal). I've had so many other issues I've not been concerned about it, but just thought I'd mention it.

[Dean Roddey]

Unfortunately, without knowing where it became sorry about that, I can't tell if it's to do with the same thing or not.

[VidaBox LLC]

OK, something is going on there, because someone else was having a completely unrelated problem that was effectively due to the the same thing. Is it creating an .ErrorInf file? Obviously some bug has creeped in with some recent change. Do you see the memory usage of the designer running up really quicky or anything like that?

Under task manager I don't see the memmory usage going up but I'll monitor that as I working. Where would I find the .ErrorInf file? There aren't any good file search options in WHS.

[Dean Roddey]

The .errorinf should be in the [cqc]\Logs directory on the machine where the designer croaked.

[VidaBox LLC]

The .errorinf should be in the [cqc]\Logs directory on the machine where the designer croaked.

I check but there is no ErrorInf from today. The ones that are in there have older dates.

[Dean Roddey]

Go ahead and delete them, so any new ones will be obvious. I'm trying to channel the code and figure out how this could be happening in the meantime.

[Dean Roddey]

Well, it looks like about 90% of allocation of system buffers is related to loading and parsing out image data in the interface viewer and designer. Normally heap memory buffers are used for smaller stuff and system memory buffers are used when there's a fair amount of memory involved.

So I'll explore that and see if someone isn't cleaning up their room as they should be.

[beelzerob]

I'm going to pull out the hard drives on my now (presumably) dead CQC box, and if I can access them I'll look for the error files.

[LesAuber]

Is there anything I can do as a reference point since so far everything is working?

[Dean Roddey]

I'll have to go back and find the other complaint and see if it was related to the interface designer. If so, then that would point towards something with the designer and not something more fundamental. If it's some other program altogether, then that would point in the more fundamental direction.

[EDIT: OK, it was Paul, and he was seeing it in CQCServer. So that would point towards something fundamental that's allocating system memory buffers, but not cleaning them up somehow I would assume. It wouldn't show up necessarily as used memory, but as virtual address space taken up. So you'd have to look at that in terms of seeing if an app is using up memory. That's the only thing that seems to make sense, so I'll explore in that direction. About the only thing likely to be a culprit is the ORB.]

[beelzerob]

I looked in the logs on the PC that was giving the occasional error/crash in the interface viewer, but no .errorinf files. :-(

[Dean Roddey]

Well, there doesn't seem to be any sort of memory leak. At least not that I can see. I've been banging around on the designer and watching the memory stats in the task manager and other than it faulting in images and such, it's not moving.

[Dean Roddey]

OK, Sergio, the only place in the whole system that tries to allocate a 16MB (max) system buffer is the HTTP client object. The only new user of the HTTP client is in the web image widget. So were you doing much work with the web image widget?

The problem may be that the web image widget was not appropriately neutered when running in the designer, so it's trying to really operate and download images, when it's not actually running in the real viewer environment. That may be a problem, so I'll fix that and get another drop up to try quickly to try out. I don't know for sure that's the problem, but it's a reasonable enough guess to go ahead and let you try it while I keep looking. It certainly won't make it worse.

[Dean Roddey]

Oh well, nevermind. That can't be it. It couldn't actually ever get invoked in the designer mode, even though it's not being explicitly held back from doing so. So I'm a little at a loss as to why someone was trying to allocate 16MB of data. And it's 16MB exactly so it's not likely that just happens to be the size of some image or something. Some code somewhere had to have decided to allocate 16MB.

Well, actually the RIVA server does allocate a system buffer that can expand to 16MB, but that wouldn't affect the interface viewer so it can't be related.

Is there a specific type of widget whose attributes you are invoking when it happens?

[VidaBox LLC]

Oh well, nevermind. That can't be it. It couldn't actually ever get invoked in the designer mode, even though it's not being explicitly held back from doing so. So I'm a little at a loss as to why someone was trying to allocate 16MB of data. And it's 16MB exactly so it's not likely that just happens to be the size of some image or something. Some code somewhere had to have decided to allocate 16MB.

Well, actually the RIVA server does allocate a system buffer that can expand to 16MB, but that wouldn't affect the interface viewer so it can't be related.

Is there a specific type of widget whose attributes you are invoking when it happens?

So far, the crashing only happens on a template where I have web images (six of them). It mostly happens when I double click the template background and in one case when I double clicked the web image. It doesn't always happen. It's definitely when I double click to bring up the attributes window. The only other thing I can think of is that I placed a dummy URL for the web images. I know you updated that in the next betas so that isn't needed anymore. I'm going to upgrade to the latest today just in case that was creating some unforeseen harm.

[VidaBox LLC]

FYI: I upgraded to .19 but still get ID to crash the same way.

[Dean Roddey]

OK, it makes sense still that it would be the web image widget, since it's the only significant new feature. So I'll dig deeper there. Maybe there is some way it was being kicked off to try to download under the designer.

[VidaBox LLC]

The crashing of ID is driving me crazy! I'm pretty much saving with every change I make.

Anyhow, I have another little bug. I get an error when I try to run a template action from "OnLoad". So doing something like IntfViewer:RunTmpAction(someaction) results in the following error when I load the template.

"The passed command (RunTmplAction) was not recognized by target 'IntfViewer'"

[Dean Roddey]

Yeh, they aren't allowed from OnLoad or OnPreload because they aren't constrained in what they can do, and therefore things that would be dangerous to be done in those commands could happen. So you shouldn't have been allowed to even configure them in those events, unless maybe you cut and pasted them in or something.

Anyway, I think I may have found the culprit. I'll have a build going while I grab some lunch then get a new drop up.

[VidaBox LLC]

Yeh, they aren't allowed from OnLoad or OnPreload because they aren't constrained in what they can do, and therefore things that would be dangerous to be done in those commands could happen. So you shouldn't have been allowed to even configure them in those events, unless maybe you cut and pasted them in or something.

Anyway, I think I may have found the culprit. I'll have a build going while I grab some lunch then get a new drop up.

I understand the limitation but it seems to me that you can run almost anything from "OnLoad" that you can run from a widget action. It would be nice if you could at least do it there. But, as it is right now, you can pick RunTmpAction from the menu so I guess you need to remove it if you meant for it not to be there.

[Dean Roddey]

I'll look at it, but I'll get a new drop up first that will hopefully take care of your issues.

[VidaBox LLC]

Another tiny one. Let's say I have a GetText command in "OnLoad". If I go into "OnPreLoad" and hit save, it compains about a missing parameter in the "GetText" command and then switches me to "OnLoad" and highlight the GetText command. Then it lets me hit save but I haven't changed anything. I'm not sure if it happens all the time but it's always in conjuction with GetText.

[Dean Roddey]

OK, I'll look at that one also.

[Dean Roddey]

I just posted .20. Give that one a try and see if it fixes the problems.

[jkish]

OK, I'll look at that one also.

Anything in .20 to fix the web images that don't display?

[Dean Roddey]

No, I just wanted to get the crashes fixed quickly before looking at anything else. Of course I might not have even fixed the crashes, but the odds were good enough to justify doing a new drop.

[VidaBox LLC]

I'm sorry to report that .20 did not fix the IE crashing issue. Sorry buddy! I was really hoping you had found it so you wouldn't spend more time on it.

[Dean Roddey]

OK, hopefully you can give me some more info. Is it always happening when bringing up the attributes of a web image widget, maybe? Something like that?

[VidaBox LLC]

I pretty much explained it all in this post:

So far, the crashing only happens on a template where I have web images (six of them). It mostly happens when I double click the template background and in one case when I double clicked the web image. It doesn't always happen. It's definitely when I double click to bring up the attributes window.

Let me know if there are others things I should look for.

[Dean Roddey]

Can you send me the template file? Not an exported package, but the raw file. Maybe I can get it to happen.

[Dean Roddey]

OK, I see what's happening now....

[Dean Roddey]

I'm still looking into some things. I know what was happening, and it shouldn't happen now. But it raised some other questions that I'm still exploring just to make sure I know what's going on. So I'm not going to get another drop up tonight.

Definitely there was too much use of the virtual address space. In various places it creates buffers where it reserves space so that the buffers can be grown if needed without having to allocate a new one and copy data over. So only some of it actually has any physical memory used, but it still takes up space in the virtual address space, of where there's generally only 2GB assigned to the user part of a given process.

The HTTP client was allocating two 16MB ones, so 32MB. And it was keeping them around instead of just allocating them when an actual HTTP transaction was going on. You then created 6 of them, so that was 200'ish MB. Then when you bring up the attribute dialog it creates a copy of the widget being edited so it can undo changes, so that was 400MB. On top of the other places where such buffers are allocated, such as in the connections to servers in the ORB (16MB per connection and you might be connected to five or six of them at a time for another 100MB) and some others. And if you had other interfaces open at the same time which also used web image widgets they'd have been sucking up more still.

So I think it was just maxing out on available virtual address space, and hence the error about not being able to allocate a block of virtual memory (which was 16MB in size and pretty certainly the memory associated with one of the web image widgets and its associated HTTP client object.)

So anyway, that was just a dumb one and the buffers were changed to only be allocated when they in use for a download (which will never happen in the designer anyway.) And some other buffers were reduced in size as well.

I just want to spend a bit more time and go through and really swat this issue and make sure that any that can be improved without doing anything dangerous are improved, and others are noted for the post-3.1 era.

[jkish]

I played with the Album template a little more and discovered that all is not well with the web image widgets. Some of them do not display anything and I see the following in the log file for each one that doesn't display:

11/15 20:08:52-automation2, CQCIntfView, CQCWebImgDLThread_Thread116
{
CIDLib, CIDLib_KeyedHashSet.hpp.1120, Failed/Not Ready, Error: 774/0/0
The TKeyedHashSet<TElem,TKey,TKeyOps> cursor is not pointing to a valid node of its collection
}

It is always the same images that won't display and there are quite a few of them. The same images that won't display in the web image widget will still display in a regular web widget.

I rebooted my master server for an unrelated reason and then ended up going to the Albums template.

It appears that the images that are visible are the first 64 that I visit.

Just to be clear, I have a set of 8 widgets on the template that get the image url set on them dynamically. It looks like only a max of 64 different images can be displayed for some reason.

[Dean Roddey]

OK, then that tells me what is wrong. I'll fix it.

[VidaBox LLC]

Another small bug. I'm on .20 beta. I'm using a Static marquee widget and have text that it longer then is displayed and the text is not scrolling. The field marquee seems to work correctly.

[Dean Roddey]

OK, I'll look at that.

[VidaBox LLC]

OK, then that tells me what is wrong. I'll fix it.

I too have hit the same bug that jkish described.

[Dean Roddey]

OK, now I really know why you were having the problem. It was what I thought, but I finally realized why it was happening so badly. I just spent an entire day trying to figure out why the interface editor seemed to be leaking info when you invoke the configuration dialog, which I noticed after I'd taken care of the issue with the excessive virtual memory usage.

Then I remembered (finally) the Undo stack. So that was making it even far worse. It was using a lot of virtual memory, and every time you invoked the configuration dialog, it has to save away the whole template in order to be able to undo it later. So multiple copies of it were stacking up there, and that would eventually just eat up virtual memory like crazy if you had a number of web image widgets on an interface.

If it ain't one thing, it's the Undo stack...

[Dean Roddey]

OK, I've got the current problems taken care of. But I'm too stupifried to get a release out tonight becasue I want to beat on it pretty hard. I'll do that tomorrow and get a new drop up some time after lunch (my time) tomorrow.

[sic0048]

I thought the only time you were allowed to eat was when IVB gets a group up to eat at the fish house. :-)

[beelzerob]

Dean, I noticed a flurry of these in my logs. I do have some macros running, but these don't reference anything I'm aware of, which of course makes debugging the macro a bit difficult.


11/20 02:17:02-bengals, CQCDrvDev, MainThread
{
CIDMacroEng, CIDMacroEng_Parser.cpp.2184, Status/App Status, Error: 6505/0/0
An unrecoverable error occured while parsing
}
11/20 02:17:26-bengals, CQCDrvDev, MainThread
{
CIDMacroEng, CIDMacroEng_Parser.cpp.2184, Status/App Status, Error: 6505/0/0
An unrecoverable error occured while parsing
}
11/20 02:17:27-bengals, CQCDrvDev, MainThread
{
CIDMacroEng, CIDMacroEng_Parser.cpp.2184, Status/App Status, Error: 6505/0/0
An unrecoverable error occured while parsing
}


If it's finding this in one of my macros, it'd be handy if I knew which macro and line number...

[VidaBox LLC]

Another little bug in .20.
I have a ListBrowser::GetCount command in "onload" for a template. I save and everything is fine. I then go back into the template "onload" and the GetCount command gets flagged as if the widget is missing. I can then add the same command again without issue and save. It's getting flagged incorrectly.

[Dean Roddey]

Dean, I noticed a flurry of these in my logs. I do have some macros running, but these don't reference anything I'm aware of, which of course makes debugging the macro a bit difficult.

If it's finding this in one of my macros, it'd be handy if I knew which macro and line number...

Assuming you within a couple beta drops of the most recent, open up the CQC Command Prompt and start it up like this:

CQCDrvDev /ModuleLog=CIDMacroEng=Info

This will turn on maximum logging in the macro engine, which may give more info in the logs as to what's going on.

[Dean Roddey]

Another little bug in .20.
I have a ListBrowser::GetCount command in "onload" for a template. I save and everything is fine. I then go back into the template "onload" and the GetCount command gets flagged as if the widget is missing. I can then add the same command again without issue and save. It's getting flagged incorrectly.

OK, I'll look at that one today as well.

[eded9698]

I'm getting this error when trying to use the Squeeze center driver.

"The server at 192.168.1.2:13507 did not reply within the requested time. Proxy class=TCQCSrvAdminClientProxy"

It was recommend that I post this here because I am using the beta .17.

I put the CQC master server IP address in the host file of the .2 computer but the result is the same.

[Dean Roddey]

I responded over in the other thread. The driver isn't responding in time so a client is timing out. Given that it talks to other things and does HTTP requests and such, I'd imagine something is not responding to it in a timely manner, so those requests are causing the driver to not be enterable for backdoor or field write operations.

[Dean Roddey]

The GetCount in OnLoad is working fine for me. Is there a specific type of list browser that you are using here that's causing the problem maybe? Or better yet, add it and then send me the interface file without going back in and invalidating it.

[beelzerob]

and start it up like this:


Start what up? I don't believe this happened while I was working on a driver, I was under the impression it happened to something that's running in the system. I have several macros that trigger for various events, I thought it would be one of them.

I *guess* they could have happened while I was in the test harness, but I really didn't think they did.

[Dean Roddey]

Start what up? I don't believe this happened while I was working on a driver, I was under the impression it happened to something that's running in the system. I have several macros that trigger for various events, I thought it would be one of them.

I *guess* they could have happened while I was in the test harness, but I really didn't think they did.

They are from the CML test harness, so definitely they happened while in there.

[jkish]

I just upgraded to 3.0.21 and the web image widgets are looking good.

[VidaBox LLC]

I upgraded to .21 and I still have the following issues:
1- ListBrowser:GetCount get's flagged in "OnLoad" as the widget not being available. I then have to manually add the action back in. Royal PITA! I hope you that fixed in the next drop.

2- Static marquee text does not auto scroll.

Everything else seems OK so far.

[Dean Roddey]

Yeh, I couldn't reproduce the first one, so I asked up there a few posts back if you could create one that you know should fail when it's opened next and send it to me before you open it again.

On #2, they are working fine for me. Can you create one of those that doesn't work and send it to me?

[VidaBox LLC]

Yeh, I couldn't reproduce the first one, so I asked up there a few posts back if you could create one that you know should fail when it's opened next and send it to me before you open it again.

On #2, they are working fine for me. Can you create one of those that doesn't work and send it to me?

Sorry! I missed that. I'll send it to you.

[Dean Roddey]

OK, I've got those taken care of. I can't imagine how the first one hadn't been noticed before. To avoid huge overhead the command editor caches the commands that each target reports it supports. But that changes for each selected event, so it has to flush that cache when you change the selected event. But, at the start, when it checks for bad commands, it just runs through them all at once, and wasn't flushing that cache. So if the first event was really limited in terms of the available commands, the subsequents ones would only see that limited list. It's hard to believe it's not been seen before, but that's the joy of software.

The scrolling thing was that the static marquee wasn't re-calculating the text length when the text was set after the fact. So the initial text length was always being kepts. If the initial text was empty or too short to need to scroll, it would never scroll, even if you did a SetText on it.

[VidaBox LLC]

Glad to see those two things getting taken care of.

Another little one that should be very easy to fix and for you to reproduce. If I enter a ~ as the text in the Variable checkbox, the bottom half of the font gets cut off so it doesn't look right. Actually, it's barely readable. Not sure if the same thing happens on other widgets. Just noticed it on that one. Another thing in the var checkbox widget, any reason why we can't set the text alignment horz and vert?

[VidaBox LLC]

Nevermind on the layout options. I just noticed the radio buttons on the first page. My bad!!

[Dean Roddey]

If you enter a tilde, that's used to indicate that the next character should be underlined, and that is probably not being disabled, so you are seeing it.

[VidaBox LLC]

If you enter a tilde, that's used to indicate that the next character should be underlined, and that is probably not being disabled, so you are seeing it.

I see like a dot. If I add another character after, I can see it and the next character properly. Just try it! You'll see it in the editor immediately not showing correctly.

[Dean Roddey]

I'm not seeing it. I've tried it in various widget types, including the variable check box. You are talking about the true/false text, right?

[Dean Roddey]

Looks like the Elk driver issue I was holding out for wasn't an issue with the driver, but too late to get a release out today. I fyou can send me a widget that demonstrates the tilde thing, I'll look at that first thing in the morning and then get a new drop out that takes care of the outstanding issues.

[VidaBox LLC]

Looks like the Elk driver issue I was holding out for wasn't an issue with the driver, but too late to get a release out today. I fyou can send me a widget that demonstrates the tilde thing, I'll look at that first thing in the morning and then get a new drop out that takes care of the outstanding issues.

Actually, it has to do with the font size. With the default font size of 12, the entire ~ shows. As you make the font size bigger, it slowing shifts down and to the right and eventually disappears all together. You are right, you place the ~ in the true/false text. As you dynamically change the font size, you'll see the tilde move and disappear eventually. I'll send you a template if you still can't duplicate it. I started a new template and was able to see the behavior so you should be able to as well.

[LesAuber]

Dean, maybe something simple for a fill in. One thing I notice about the XLAT function is it's a bit of a pain to change one thing because you have to delete the line and start over? For example if you type Coax2 instead of Coax 2 it's delete instead of just editing the space. Little creature comfort.

It also would be nice to be able to set what a field in error state displays. ???? isn't obvious to a casual observer.

[Dean Roddey]

Yeh, that's already on the list, just not gotten to yet. I'll slip it in at some point here.

[LesAuber]

Thanks, sorry for posting in the wrong thread. Thought I was in the beta not the release thread.

[Mark Stega]

Above 3 posts moved from official beta release thread to here

[Dean Roddey]

Any folks using the latest (.22) beta drop? I would think that one should be getting pretty tight and stable?

[George M]

I went from .17 to .22. I lost album art while using jkish's templates. Don't know if it is associated with .22 or not. Have to run out and don't have the time to look at right now.

[VidaBox LLC]

Actually, it has to do with the font size. With the default font size of 12, the entire ~ shows. As you make the font size bigger, it slowing shifts down and to the right and eventually disappears all together. You are right, you place the ~ in the true/false text. As you dynamically change the font size, you'll see the tilde move and disappear eventually. I'll send you a template if you still can't duplicate it. I started a new template and was able to see the behavior so you should be able to as well.

Dean,

Where you able to reproduce this and fix it? I'm on .22 and things are looking good. I'm still getting the same issue I posted about a couple of days ago:

Another tiny one. Let's say I have a GetText command in "OnLoad". If I go into "OnPreLoad" and hit save, it compains about a missing parameter in the "GetText" command and then switches me to "OnLoad" and highlight the GetText command. Then it lets me hit save but I haven't changed anything. I'm not sure if it happens all the time but it's always in conjunction with GetText.

It's also coming up on other commands as well but I don't remember which.

Also, a slight a improvement if possible. I think it would be much easier if when inserting a variable token from the new window/menu you created, if it would replace the highlighted text in the action command instead of deleting everything and placing the variable token. Most of the time, I'm replacing part of a field definition with a variable holding a moniker name or stuff like that. If nothing is highlighted, then I think a complete replacement would be fine. Secondly, it would be nice if the variable could be shown in a list form instead of dropdown box. It would be better if you could add a column to the list (or drop down if you decide to keep that) with the description for the variable. That way, one can find a variable more quickly because they would see the description next to it to explain what it does. This is more helpful for people that would get templates from others.

[pseigler]

Any folks using the latest (.22) beta drop?

i upgraded a large install to .22, from .17:

(i) the CQC service, which was not automatically starting on reboots, is now starting

(ii) appears that drivers are starting up faster after a CQC Service restart

(iii) all of the canned and custom drivers/macros appear to be running smoothly

[Dean Roddey]

I think it would be much easier if when inserting a variable token from the new window/menu you created, if it would replace the highlighted text in the action command instead of deleting everything and placing the variable token.

Yeh, I agree.

Where you able to reproduce this and fix it? I'm on .22 and things are looking good. I'm still getting the same issue I posted about a couple of days ago:

I haven't looked at it yet. I was a little lazy yesterday and kind just worked casually on some unit tests.

[Dean Roddey]

It's basically what I thought. In order to support the standard underlining stuff, the methods that calculate the area of a string (in the current font) have an option to ignore the tilde, since if it's being used to do the standard underline, it won't be in the final string. So the area being calculated for the string is missing the contribution of the tilde, which is small in a small font, but grows as the size of each character gets bigger and eventually starts cropping the text.

[robolo]

Dean,
I had been away from this for a little bit but I just tried update to 3.0.22 and I'm still having the problem with the web image widget refusing to update an image for 30 sec. Remember this image has a header of "no cache" but the widget still wants to cache it anyway.

Robert

[Dean Roddey]

I've been through that stuff as best I can. I couldn't find any image on the web that has a no-cache status (which was an actual image and not something generated by code, so that I could access it via the web image widget.) So I haven't actually found a way to test it yet, and have just gone through it by eye, though definitely it should be working as best I can tell now.

[robolo]

Let me see if i can get you access to my web imagae server. In the meantime i just want to confirm that the RIVA client should be able to pick up the web image widget images from the RIVA server, right? My client is not displaying the images of the web image widget.

[Dean Roddey]

Some new stuff will have to be added to support web image widgets on the RIVA client, because it involves non-repository images. There will have to be a command added to pass the URL to the RIVA clients and have them come back and get them. So that will likely be a post-3.1 thing.

[SamVimes2]

+1 for web image widget support in the RIVA.

[robolo]

Dean,
Seriously, don't kill me....

I discovered that I was sending the non-parsed header version of the image instead of the regular header version. Once I redirected to the correct header version everything is right with the world....the image updates with every refresh.

Now if I could only get this passed to the RIVA client............

Robert

[Dean Roddey]

OK, that makes more sense. Otherwise I was going to has to start questioning my sanity, and I don't need any new reasons to do that.

[VidaBox LLC]

Some new stuff will have to be added to support web image widgets on the RIVA client, because it involves non-repository images. There will have to be a command added to pass the URL to the RIVA clients and have them come back and get them. So that will likely be a post-3.1 thing.

Will the web widget show on the simple RIVA protocol/client?

I know you don't want to add to much stuff to the current beta at this point but I really thought the the web widget was going to working in RIVA. I'm using the web widget mostly for the squeezebox like most here probably and I need to design some pages for a RIVA client for a current job. That's why I pushed you getting the web widget out. If it's not in RIVA, then I'm afraid I'm stuck on this job which needs to be completed by mid Dec.

[Dean Roddey]

Yeh, on the simple protocol it will work. Which RIVA client are you using? I can add it to the full protocol on the server, but it will still need to be implemented in the clients, so if you are using the .Net one, Mark will have to do the work to support that.

[VidaBox LLC]

Yeh, on the simple protocol it will work. Which RIVA client are you using? I can add it to the full protocol on the server, but it will still need to be implemented in the clients, so if you are using the .Net one, Mark will have to do the work to support that.

It would be the compact framework RIVA (developed by Mark) so it uses the simple protocol. If it works there, then I don't need you to implement anything in a hurry at this moment. I'll be working on the CF RIVA pages next week so I'll post anything that might come up.

[Dean Roddey]

So, in order to keep my dirty hands out of more dangerous stuff, today I implemented some long discussed improvements to the blanker.

1. I added the ability for it to display a slowly rotating current time
2. I added a new special action that can invoke in that clock mode
3. I added a new command, IntfViewer::SetAutoBlankMode() which can tell the viewer to use the Blanker, Blank&Blanker, or Clock Blanker modes when it auto-times out.

Of course this was supposed to be a fairly quick thing and then I was going to do a couple other little things and get a new drop out. But it didn't turn out so simple. But it's there now. Tomorrow I'll do the thing Sergio suggested above about the insertion of runtime value, variable, and field tokens so that they insert at the cursor point and replace only selected text (if any), then I'll get another drop up there.

If no one finds anything wrong over the course of the week, I think we can declare it a 3.1 release, so I'll get into a heavy documentation mode, and I'm going to have to update some videos as well.

[jrlewis]

Any plans in the not too distant future for writing back out to XML files? Targeting elements with string manipulation isn't too painful, but attributes would be a bit more and I would rather not add them to the mix if I don't have to.

And something along the lines of the insertion issue is when you have a section of text that contains the first character selected in any dialog if you hit backspace it won't delete the selection. I'm sure it is your validation routine. Delete works, but it is just a force of habit to hit the backspace to delete selected text.

[DaveB]

So, in order to keep my dirty hands out of more dangerous stuff, today I implemented some long discussed improvements to the blanker.

1. I added the ability for it to display a slowly rotating current time
2. I added a new special action that can invoke in that clock mode
3. I added a new command, IntfViewer::SetAutoBlankMode() which can tell the viewer to use the Blanker, Blank&Blanker, or Clock Blanker modes when it auto-times out.

Of course this was supposed to be a fairly quick thing and then I was going to do a couple other little things and get a new drop out. But it didn't turn out so simple. But it's there now. Tomorrow I'll do the thing Sergio suggested above about the insertion of runtime value, variable, and field tokens so that they insert at the cursor point and replace only selected text (if any), then I'll get another drop up there.

If no one finds anything wrong over the course of the week, I think we can declare it a 3.1 release, so I'll get into a heavy documentation mode, and I'm going to have to update some videos as well.

Dean - What you should do is allow the Blanker to be an editable scene, that other items could be placed onto. Make it an open format for design purposes. You may want to limit what actually could be added, but I for one would like more capability that just a clock.

[Dean Roddey]

If you want more than that, you could probably just do that yourself. Have a timeout in the base template that is set for inactivity time. When it goes off, run a popup that fills the whole screen and has whatever info you want on it, plus a button to close it. If the viewer is in full screen mode, then the popup will cover the whole screen.

We can look at expanding the blanker more in the future, but for now that was just a fairly low priority one that was slipped in while we are in the pre-release cool down.

[DaveB]

I have about a dozen more that ae equally important, but I will hold back for the right opportunity...

[sic0048]

I'm surprised no one has said anything about this, but I swear I cannot get the LinkToField command to work in the OnPreLoad action of the base template. If I move it to the OnLoad action, it seems to work fine.

I'm OK with moving them all to the OnLoad section, but I'd recommend you remove the LinkToField option in the OnPreLoad actions if this is the final solution.

I did some major tweaks to my templates over the weekend, so it might be something else. But I've seen this issue before and had placed all my LinkToFields to the OnLoad actions. One of the changes I did was to move them back to the OnPreLoad actions. Now my GVar Checkbox widgets don't reflect the currently selected source properly.

Tonight I'll double check it is the OnPreLoad actions that are causing problems by simply copying those actions to the OnLoad section. I would have done this last night but ran out of time. I figured I would say something now so that Dean could check it if it is something relatively easy for him to do.

[jkish]

One of the problems I run into (and I'm sure other do as well) is that you have to remember any triggers that have been applied to fields when you reinstall drivers as there is no way to save those away. This gets worse now when you can have functionality tied to events in the templates.

How about having an option for triggers to be created automatically for event handlers in the IV and triggered events?

They could just default to the 'Trigger on any change' setting as that is probably the most used. This way, my triggers would reappear if I reinstall my drivers and templates that are shared would create any triggers needed.

[VidaBox LLC]

I'm surprised no one has said anything about this, but I swear I cannot get the LinkToField command to work in the OnPreLoad action of the base template. If I move it to the OnLoad action, it seems to work fine.

I'm OK with moving them all to the OnLoad section, but I'd recommend you remove the LinkToField option in the OnPreLoad actions if this is the final solution.

I did some major tweaks to my templates over the weekend, so it might be something else. But I've seen this issue before and had placed all my LinkToFields to the OnLoad actions. One of the changes I did was to move them back to the OnPreLoad actions. Now my GVar Checkbox widgets don't reflect the currently selected source properly.

Tonight I'll double check it is the OnPreLoad actions that are causing problems by simply copying those actions to the OnLoad section. I would have done this last night but ran out of time. I figured I would say something now so that Dean could check it if it is something relatively easy for him to do.

I've commented on this very problem as well but it has yet to be resolved.

[sic0048]

I've commented on this very problem as well but it has yet to be resolved.

Yeah, I should have said something like "I'm surprised more people are not complaining about this" I thought it had been mentioned before, but didn't remember exactly.

At least it's confirmed that it does appear to be a problem. Hopefully Dean can resolve it one way or another - either get it fixed, or remove the LinkToField option from the OnPreload actions.

[VidaBox LLC]

Yeah, I should have said something like "I'm surprised more people are not complaining about this" I thought it had been mentioned before, but didn't remember exactly.

At least it's confirmed that it does appear to be a problem. Hopefully Dean can resolve it one way or another - either get it fixed, or remove the LinkToField option from the OnPreload actions.

It's a tough one for Dean to troubleshoot as it works 99% of the time. I myself have only encountered the issue on one template.

[pseigler]

(i)
with the new extended logging coming up quickly, would it be possible to expose this to the XML gateway? this would open up the door to allow products such as tivoli, MS Operations Manager and other high end management packages to monitor and report on CQC.

(ii)
can the CQCGW:WriteField message be setup to accept multiple fields to write. This would greatly speed up the process of 3rd party interfaces sending CQC information.

(iii)
are there plans to expose scheduling via the XMLGateway. again, another feature that would open the door for higher-end integration with CQC.

[Dean Roddey]

We can look at those Gateway improvements post 3.1. I'll take another look at the link to field. It's got to be some sort of timing thing I guess, if it's not consistent.

[pseigler]

We can look at those Gateway improvements post 3.1.

Can't wait. thanks Dean

[SamVimes2]

Note that the new clock blanker thing won't be understood by the remote viewers (even if they otherwise support blanking requests), since that's not been added to the RIVA protocol yet. That and support for web image widgets will be added in the next release.

Dean, will this stuff be in before 3.1? Not trying to nag, just trying to figure out timing of the iPhone RIVA viewer. We're feature-complete as of today, but if the web image widget we'll be soon we should potentially delay filing with the app store until we get it in.

Thanks for any advice!

[Dean Roddey]

I'm not going to try to get it into 3.1. It's too late in the cycle for that. We need to be in strict lock down mode for a week or so and only fix serious, non-workable around bugs.

[Dean Roddey]

So I'm definitely having trouble seeing how the link to field can fail. The OnPreload actions are run synchronously before the load continues. So it can't be a timing thing due to async invocation of the OnPreload. Either the OnPreload would have to fail (in which case there would be an exception) or it has to have set the field before continuing on to register the fields and such.

Any more info as to specific circumstances when this happens? If someone has a template that consistently displays this error, send me the template. The raw file, not a template pack. And, if you could copy the template and reduce it down to the minimum example that will cause it to happen, because if it's some complex template with lots of drivers and fields, I'll never get a reasonable simulation of that set up in order to be able to run it.

One thing you might do, in the process, is copy it, then start removing widgets one at a time, and reload it after each one. If it stops having the error at some point, that would definitely point in a certain direction if you can tell me what type of widget it was.

[IVB]

I just read through all the 3.1 release notes. At first glance, it doesn't seem like there's anything in there that would be very noticeable for those of us with stable systems. (as opposed to 3.0, which had some very cool new stuff).

But, I acknowledge that I didn't actually understand 50% of those notes. Anybody out there with a stable system find something in here that compelled them to upgrade? What new thing were you able to do as a result?

[Dean Roddey]

I think that the big ones would be:

1. The logic server is the biggest one. It would make various things that were tough or kludgey to do now much easier.

2. Timed events in the interface viewer to do things like auto-timeout popups and or auto-hide widgets that were made visible via incoming events, whereas before it often required a timer driver field.

3. Web image widgets, which keep you from having to use a web browser widget and all of the issues that implies in order to view web server based images.

4. The RIVA system is all nicely vetted and working now. The native RIVA client is probably much nicer than the regular standalone viewer on lower powered and wireless clients, particularly wrt handling periodic drops of the network.

[sic0048]

OK Dean,

I'll send you the templates, but here is my scenerio with the LinkToField commands failing in the OnPreLoad actions.

Below is a picture of the IV and the AI. Look at the highlighted "Room" button at the top of the picture. It shows the "Sun Room" as the currently selected room, but shows the "DVR" as the currently selected source (button on right). This is not reflecting the current value of the Driver field which shows the current source for that room as "CD 1"

http://i185.photobucket.com/albums/x46/sic0048/LinkToField-InPreload.png

That is with the LinkToField Commands in the Preload section of the action.

Second picture shows the correct source being shown for that room. The only change I made was to move the LinkToField commands from the Preload actions to the OnLoad actions. No other changes were made. The viewer now reflects the correct source for that room.

http://i185.photobucket.com/albums/x46/sic0048/LinkToField-InOnLoad.png

Here is a screen shot of all the LinkToFields in question (this is after they have been moved to the OnLoad actions).

http://i185.photobucket.com/albums/x46/sic0048/OnLoadActions.png

Attached are the Action Trace report that represents how we got to this place in the IV. There is one with the LinkToFields located in the OnPreLoad action area, and other with the LinkToFields in the OnLoad action area. No other changes were made between these two files being created or the screen shots being taken.

At no time do I get an error message with the LinkToFields in either location. They simply don't link properly when in the OnPreLoad actions.

[jrlewis]

Any plans in the not too distant future for writing back out to XML files? Targeting elements with string manipulation isn't too painful, but attributes would be a bit more and I would rather not add them to the mix if I don't have to.

And something along the lines of the insertion issue is when you have a section of text that contains the first character selected in any dialog if you hit backspace it won't delete the selection. I'm sure it is your validation routine. Delete works, but it is just a force of habit to hit the backspace to delete selected text.

Any plans for XML support for editing/creating as opposed to just reading?

[VidaBox LLC]

I've been working with the .24 release. I know I requested that you change how tags and tokens get inserted for commands but I don't think I like how it is implemented at the moment. I like that I can replace just the highlighted portion with the token or variable that I want to insert. However, I find it awkward that it inserts newly selected items and tokens where I have my cursor placed (when nothing is highlighted). I think it would work better that if you don't have some text highlighted that it work the old way and replace the entire contents with the new token. If something is highlighted, it should replace just the highlighted part. I'm finding that I'm making too many mistakes as I'm used to the old way of selecting fields, template names, etc and the new way just adds it to exiting string content were the cursor is placed. I think what I propose would be a good compromise.

Edit:
Actually, as I'm using this more. It might be better if when you click on the notepad icon, it always replaces the entire contents of the textbox. If you right click to get a token, it replaces the highlighted text or inserts where the cursor is. In the end, it's a little awkward the way it is right now. You might have other suggestions.

[VidaBox LLC]

I'm encountering two new issues:

1- I have a field slider widget tied to a read only field with a range of 0-100. I get an error when the slider is set to a new position. I'm doing my own logic in the onSet so I don't need the slider to automatically write the new value to the field. Actually, it would be very nice if this could be an option that could be set on the slider. By default, write the new value to the driver but if a checkbox is checked, no value is written. Otherwise, it should really check if the field is writeable before trying to write a new value.

2- LocalVar::Add does not accept any numeric value with a decimal point in the value field. Other commands might have the same issue. Haven't tried them all. So we can't do any floating point math.

[VidaBox LLC]

Eventually after hitting undo multiple times, interface editor crashes.

[VidaBox LLC]

Sorry for all these posts Dean but I want to make sure you about this bugs as I come across them.

There is definitly something wierd going on with OnPreLoad. I lost 30 minutes trying to figure out why some of my widgets weren't hiding and showing correctly based on some logic I placed in the OnPreLoad. I was hiding and showing widgets based on the value of a field. Only the last widget that I set to hide or show would take the command. The others would always show regardless if I set it to false or if I set the visibility to false in the widgets attribute. Placing the exact same commands/logic in OnLoad worked flawlessly.

[Dean Roddey]

Edit:
Actually, as I'm using this more. It might be better if when you click on the notepad icon, it always replaces the entire contents of the textbox. If you right click to get a token, it replaces the highlighted text or inserts where the cursor is. In the end, it's a little awkward the way it is right now. You might have other suggestions.

I started to do it that way, but then didn't. I do think that would probably be better.

[Dean Roddey]

I'm encountering two new issues:

1- I have a field slider widget tied to a read only field with a range of 0-100. I get an error when the slider is set to a new position. I'm doing my own logic in the onSet so I don't need the slider to automatically write the new value to the field. Actually, it would be very nice if this could be an option that could be set on the slider. By default, write the new value to the driver but if a checkbox is checked, no value is written. Otherwise, it should really check if the field is writeable before trying to write a new value.


You could always just use a static slider for that kind of thing.

2- LocalVar::Add does not accept any numeric value with a decimal point in the value field. Other commands might have the same issue. Haven't tried them all. So we can't do any floating point math.

Yeh, this was discussed elsewhere. Currently there are only signed and unsigned parameter types. What we need is another one which is just 'numeric' for those types of commands, really only the math commands generally, that have to get a numeric value but it can be any kind of numeric value.

That's something that will have to wait for post-3.1, because it would have been too dangerous to do this late in the game.

[Dean Roddey]

Sorry for all these posts Dean but I want to make sure you about this bugs as I come across them.

There is definitly something wierd going on with OnPreLoad. I lost 30 minutes trying to figure out why some of my widgets weren't hiding and showing correctly based on some logic I placed in the OnPreLoad. I was hiding and showing widgets based on the value of a field. Only the last widget that I set to hide or show would take the command. The others would always show regardless if I set it to false or if I set the visibility to false in the widgets attribute. Placing the exact same commands/logic in OnLoad worked flawlessly.

OK, that makes more sense to me, that it's just someting about OnPreload generally and not just about LinkToField. I was looking at it from the perspective of why LinkToField doesn't work, since that's all anyone had reported. So I hadn't look at it from the perspective of why maybe OnPreload might not always be firing, or not firing correctly.

Is this, by any chance, only in an overlay or only in a popup? Any specifics like that would make it easier to hone in on prehaps.

[VidaBox LLC]

OK, that makes more sense to me, that it's just someting about OnPreload generally and not just about LinkToField. I was looking at it from the perspective of why LinkToField doesn't work, since that's all anyone had reported. So I hadn't look at it from the perspective of why maybe OnPreload might not always be firing, or not firing correctly.

Is this, by any chance, only in an overlay or only in a popup? Any specifics like that would make it easier to hone in on prehaps.

This happens to be in an overlay.

[VidaBox LLC]

You could always just use a static slider for that kind of thing.

In this case I can't because I want to track the field dynamically. There are other workarounds but I would rather not do them. Is this something you can fix?

[Dean Roddey]

That would be dangerous to do at this point. But, if I end up having to change something related to actions to deal with the OnPreload, then we'd be in the same boat and it wouldn't make it any worse at that point.

[Dean Roddey]

OK, I see what's going on. Hard to imagine it could have been that way for so long and not be noticed. OnPreload isn't running if you have an initially selected template. I'll have to think about this one carefully and what to do about it.

[VidaBox LLC]

OK, I see what's going on. Hard to imagine it could have been that way for so long and not be noticed. OnPreload isn't running if you have an initially selected template. I'll have to think about this one carefully and what to do about it.

Hmm! In the template were my widgets weren't hiding, I didn't have an initial template selected and I know some of the OnPreLoad commands ran but it ignored some of the Hide/Show commands. In another case, I did have an initial template selected and non of the commands ran. However, with that same overlay, I had OnPreLoad run with no issues with other templates I loaded into it.

[sic0048]

I can confirm that moving back up one template and changing it so it did not automatically load the Source Selection template did fix the problem I reported. Now when I load the Source Selection template, the LinkToFields do work even while in the OnPreLoad section.

[Dean Roddey]

I've got it working now. Another thing that was happening was the the fields were being registered with the polling engine twice in the case of an automatically loaded overlay. This isn't dangerous, but it slows down the loading of the overlay a bit.

[IVB]

4. The RIVA system is all nicely vetted and working now. The native RIVA client is probably much nicer than the regular standalone viewer on lower powered and wireless clients, particularly wrt handling periodic drops of the network.

Where exactly is the .24 version of the RIVA PDA client?

[Dean Roddey]

It's no longer really tied to the CQC version because it's so much disconnected from the actual details of how the interface system works. There will obviously at some point be some version specific things that an older version of the RIVA client won't do where new ones will, but generally there won't be a need to update the RIVA clients when a new CQC version comes out, which is one of its big advantages since it's oriented towards embedded devices a lot and such.

Anyhooo, if you go to the beta web site (there's a link in the same sticky post at the top of this section that has the link to the latest beta), there on the Try/Buy -> Try It page there's a download for it, and that's where it'll be when this beta content soon becomes the for real content.

[Dean Roddey]

OK, I've got the current crop of issues fixed and as best I can tell I've broken nothing. The changes in the end were fairly simple, just hard to figure out which simple changes were required. I've got a production build going. I'm going to go get a little air, and I'll bang on it some more when I get back and then post it so that it'll be there for Sergio in the morning.


Go back to the parameter selection value button replacing the whole parameter, and leave the popup insertion stuff replacing the current selection (or just inserting at the cursor point if no selection.)
Allow most of the static text widget commands to be invoked in OnPreload, since they can't be dangerous.
The OnPreload event is not being correctly invoked when an overlay is loaded via the initial automatic load mechanism.
Provide a new optional 'no auto-write' check box on the field selection tab. Widgets that support it will allow the check box to show up, and the user can control whether that widget will automatically write to its associated field. Implement this in the field based slider and volume knob widgets for now. And, BTW, get rid of the 'allow direct writes' controls on that tab as well, since those are no longer supported.

[VidaBox LLC]

Eventually after hitting undo multiple times, interface editor crashes.

You probably missed it with all my posts yesterday but I didn't see a mention of a fix for this in your beta notes.

Thank you very much for getting in the change I requested for the field slider. Really appreciate that!

[jrlewis]

A desired feature for a slider would also be to have a read only option so it acted as an indicator instead of an input control.

[VidaBox LLC]

A desired feature for a slider would also be to have a read only option so it acted as an indicator instead of an input control.

I know it's a hack but you can place a transparent static widget on top of the slider so that the user can't click on it.

[sic0048]

A desired feature for a slider would also be to have a read only option so it acted as an indicator instead of an input control.

I think with the last beta this feature was basically obtained. Now you can select a "no write" option. So if I user clicks on it, it won't actually write to the driver field it is representing.

[jrlewis]

I use the empty blocking image, but would rather not as it makes editing a bit of a pita and you always have to keep track of an extra widget.

It looks like the constructor for the StringList isn't honoring the UniqueOnly attribute. I have a sorting routine in the Pandora driver and it is erroring out when adding a duplicate to a list even though it is constructed with False for the UniqueOnly attribute.

[VidaBox LLC]

OK! I am using the .25 beta and have the following issues/updates to report:

1- I still have an issue with Hide/Show in OnPreload. I have found that it is limited to trying to hide/show a field text widget. Other widgets hide/show properly in OnPreLoad.

2- The linktofield issue I had on one template has been fixed with this version.

3- New issue: It seems that a template that is selected to initially load in an overlay get loaded at the same time as the template the container is in. Meaning, the OnPreLoad for the overlay template runs at the same time as the owner OnLoad. So if some GVars or stuff needs to be set first in the owner template that the overlay template needs, the overlay template might not have what it needs to load. It used to be that the owner template onload goes first, then it would load overlay templates and the executing order was kept straight. The workaround right now is that I can't load an initial template in the overlay. Do the commands I need in the owner template and then load the overlay from the owner onload. It's not a big deal I guess. It just behaves differently from before.

4- I still have an issue with commands getting flagged as invalid in OnLoad even if they are correct. This time it was in relation to a getcount command in onload. So if I'm in OnPreLoad and click save. I get a pop-up complaining about the GetCount command and opens the OnLoad page. I can then click save without making any changes. So something is getting flagged incorrectly.

[Dean Roddey]

On #3, best to move the creation of variables into the OnPreload of the parent template, to insure it's set before the overlay OnPreload gets run. The correct order, in theory, should be Parent preload -> Child preload -> Parent load -> Child load.

I'll look at the others. Is #1 perhaps just a display issue? I.e. is you were to minimize and restore the viewer, would the widget then hide? I'm wondering if it's getting drawn before it gets hidden and then somehow not getting re-drawn in hidden state.

[Dean Roddey]

OK, just looking at the code I think that the child's OnPreload IS running before the parent's, which is bad. I think I'm going to have to add a separate recursive pass to kick off all of the OnPreloads, in order to control the ordering. Either that or move the loading of initial templates until after the parent is fully initialized. But I think that the above order is probably really correct, i.e. preloads in recursive order, then loads in recursive order.

[VidaBox LLC]

On #3, best to move the creation of variables into the OnPreload of the parent template, to insure it's set before the overlay OnPreload gets run. The correct order, in theory, should be Parent preload -> Child preload -> Parent load -> Child load.

I create a variable in the parent OnPreLoad. The child template looks for that variable on PreLoad but complains that it's not created so something is off on the order in which things are running. I don't think it's running as you described.

[VidaBox LLC]

OK, just looking at the code I think that the child's OnPreload IS running before the parent's, which is bad. I think I'm going to have to add a separate recursive pass to kick off all of the OnPreloads, in order to control the ordering. Either that or move the loading of initial templates until after the parent is fully initialized. But I think that the above order is probably really correct, i.e. preloads in recursive order, then loads in recursive order.

Maybe Mark and others can chime in but I think that it should run Parent OnPreload -> Parent OnLoad -> Child OnPreload -> Child OnLoad. Otherwise, It's kind of confusing to track what will fire when. However, there maybe be a very good reason to run it the way you describe.

[Dean Roddey]

Preloads have to run synchronously, so they have to come first, and they need to pass through the whole recursive structure before moving forward. Without this, any setup that would be done in the child on preload won't be done by the time the parent starts interacting with it in a way that assumes it's fully ready to use.

[VidaBox LLC]

I'll look at the others. Is #1 perhaps just a display issue? I.e. is you were to minimize and restore the viewer, would the widget then hide? I'm wondering if it's getting drawn before it gets hidden and then somehow not getting re-drawn in hidden state.

I minimized and maximized but the widget doesn't hide. I tried to duplicate the behavior on a more basic template but couldn't duplicate the issue. The issue seems to be specific to this particular template. An edit on what I previously posted, the widget that doesn't hide is a field time widget. Other widgets on the page hide with no issues. This template is a tough one to send you because it is rather complex and I don't know how you could run it stand-alone in a meaningful way.

Sorry! I tried to nail it down a bit more so you could duplicate on your system but I can't.

Edit: Some more info, not sure if it makes a different. This is the only template that I have states setup. I disabled the state on the widget I was trying to hide on OnPreLoad but it made no difference. The order of execution is base template -> pop-up template -> child overlay template in pop-up. I'm hiding the field time widget in the onpreload of the child template.

[Dean Roddey]

I'll take a look at the template time widget. It may not be honoring the hide thing or something. It may be because some other widget is intersecting it in the more complex widget, causing it to redraw, whereas in the simpler one it's not, or something like that.

[Dean Roddey]

OK, I found the answer to some wierdnesses. When the on preloads in the template and overlay is being set up, it was recursively finding all possible targets, not just targets that are children of the template or overlay. So if a widget in a child overlay had the same name as a widget that you are actually targeting, you could actually get the one down in the child template. Doh! No telling what type of wierdness that could have caused. Whether you'd get the nested one or the correct one is a crap shoot becasue it's a hash based list, so the order depends on the hash of the name.

Is it possibly the case that some of your mystery failures in the OnPreload are ones where a nested widget has the same name?

[VidaBox LLC]

OK, I found the answer to some wierdnesses. When the on preloads in the template and overlay is being set up, it was recursively finding all possible targets, not just targets that are children of the template or overlay. So if a widget in a child overlay had the same name as a widget that you are actually targeting, you could actually get the one down in the child template. Doh! No telling what type of wierdness that could have caused. Whether you'd get the nested one or the correct one is a crap shoot becasue it's a hash based list, so the order depends on the hash of the name.

Is it possibly the case that some of your mystery failures in the OnPreload are ones where a nested widget has the same name?

I don't think I had other widgets named the same on other templates that might be loaded. But to make sure, I name the widget something I was sure was unique. But I still have the same behavior. Sorry! I'm glad you found this other issue however :)

[Dean Roddey]

How about on the hide/show thing?

[VidaBox LLC]

That's what I tested. I placed a Hide/Show in OnPreLoad and it doesn't hide the widget. I made sure I named it a unique name.

[Dean Roddey]

I'm not having any problems with the time widget hiding. I set up some field time widgets which I hide in the load and preload, and then the same set in an overlay hidden in the same way, and I have a button to invoke it as a popup as well, and they hide correctly in all cases, whether hide if zero is set or not set.

Maybe it's because, in your more complex scenario the initial value of the field isn't being gotten for longer and that initial coming on line isn't honoring the visibility setting. But I just tried killing and restarting CQCServer so that the fields would go offline and come back online and that didn't make them show up, even if I loaded the widget with the driver dead.

I'm going to go ahead and get a drop out to deal with the other issues. It's still feasible something I fixed was really causing this, so let's see if it's still an issue after this next drop before I spend more time on it.

[VidaBox LLC]

I'm working on .26 but I have to say that the order of things firing in OnPreLoad/OnLoad between parent and child templates is very different from before. Some of my templates aren't running correctly now because of the new way in which the events fire.

Let me describe what is happening:
I have a template that has 8 overlay containers. In the OnLoad for the parent template, I set a global variable and load a template into the first container. I then repeat the process by changing the GVar to a new value and loading the same template into the second container. I repeat the process for the remaining overlay widgets. On the child template that gets loaded in the overlays, it reads the GVar and does some logic depending on the value. I have actions in both OnPreload and OnLoad in this template. What I see happening is the OnPreload fires in the child template with each overlay::loadtemplate call and it reads the GVar value that was set just before the call. However, the OnLoad for the child template doesn't fire until the OnLoad for the parent template is finished. Therefore, OnLoad only sees the last GVar value that was set, not the GVar value that is set before I issue the overlay::loadtemplate. I hope that makes sense.

It used to work perfectly and has worked that way since I started with CQC and once the OnPreLoad event was added. I think that the old way is the way it should work but I understand that sometimes things need to change but in this case, I think you need to consider this change very carefully as you are changing the logic of something was part of a shipping version. I don't want to have to explain to my customers why then need to go and change potentially lots of logic because of an upgrade to a new version. A breaking change is almost always a tough one to handle. So I ask that you consider this breaking change very carefully as this could have a pretty big impact at least with my costumers as most of them use my templates in one form or another.

That being said. Thankfully, you added many more commands in OnPreLoad so I was able to move all the commands I was running in OnLoad into OnPreload and my templates work perfectly now. I'm going to leave it this way now. My objection mostly has to do with the potential extra work that one would have to do if they decide to upgrade to a new version.

[Dean Roddey]

The gotcha I think is that no order will always make everyone happy. It depends on whether you look at the purpose of these things as a way to set up circumstances that nested overlays will see, or to set up nested overlays so that the containing layer can then interact with them already set up.

There are arguments for either way I guess. I took the approach that it's always the former, so in the pre-load and load passes you'd want the outer layer to first first then move inwards one step at a time.

The difference I think that you are seeing is that previously the OnLoads were done the other way. I guess that could be a valid scenario. That the preloads move downwards, so that each layer sets up variable and field linkages and such in preparation for the nested layers, and that then the OnLoads happen outwards so that each layer finishes up its setup before moving up to the containing layer.

That would work as well, I thought it was just probably a bad thing. but I can put it back that way easily. That would prevent breakage and I guess it's equally valid.

[VidaBox LLC]

or to set up nested overlays so that the containing layer can then interact with them already set up.

There is very little to nothing that the parent template can do to effect widgets that are already loaded into the child template other than using GVars so it ends up being of very limited use if the child template only gets the GVar after the parent onload is finished. That's why I think the original approach was better.

[Dean Roddey]

Yeh, that's true, they don't have direct access. But, just to make sure that we are on the same page....

OnPreload works downwards. So OnPreload is clearly where you would set up the environment that you want nested layers to see. That's always the way that was intended to work (the gotcha being that the firing of OnPreload not working correctly in automatically loaded overlays.) And more stuff will be enabled in the preload over time, the ones that are safe to do.

The other gotcha is that now all the onpreloads run, then all the onloads run. I think that's really the way it should work. Preload actions need to happen at a particular point in the process of setting up the widgets.

Before I think that the two steps were potentially interwoven. But that's not a very good way to do it, because the preload actions are synchronous, so you are guaranteed that they will happen in the process of loading the template, before any drawing is done, before any fields are registered, etc... OnLoads are not run synchronously, and can't be guaranteed to run before drawing and field registration is done, and they can kick off nested actions and so forth. There's also no way to guarantee that all of the onpreloads will complete before onloads start happening, which could explain some subtle issues that have been seen.

So I really think that it's correct to run all the preloads and then all of the loads. The way they are now, the outer layer in each pass can affect what the nested layers see, since the outer layers run first. The onpreload will set up variables in the outer layers, and the inner layers will initialize themselves using those and set up field linkages and such. Then the onload is used for stuff that can't be safey done until everything is fully set up and ready, though that could potentially also include setting up more variables, i.e. it's possible that in the onpreload a nested widget set a variable that the outer layer then subsequently uses in the onload.

But the intermixing of them, that's really kind of technically bad and never how it was intended to work, because there's no way to insure that the onload of the outer layer won't start happening before all nested inner layer preloads have completed.

[VidaBox LLC]

I see what you mean. All of this is really complex and not easy by any means. I guess I'll let you do what is best for future progress. If you feel this should be set the what you outlined now than I'll just deal with what will come in the future as people upgrade. As it is right now, it's not terrible to fix. Just a cut and past into the OnPreLoad.

What would be nice to add (post 3.1) is a "friend" variable space that would be template specific. So the variable would be available between widgets on the same template but not to other templates. The way I get around this right now is by tucking away the value into a hidden static text widget on the page. I read the value from the widget whenever I need it. It would make the programming so much cleaner if I could just read the variable directly. Anyhow, just putting it out there. Not keeping my hopes up that you will add it.

[Dean Roddey]

OK, so the hiding of the time text widgets turns out to be, ironically, a timing thing. The problem is that the 'hide if zero' really just automatically sets the widget's hide/show state for you. So you cannot override that by hiding the widget manually. It will just show up again if the value is non-zero, every time the field value changes.

If your manual hide/show happens to come after the initial field value comes in (which will show the widget if it's non-zero and the hide if zero thing is checked), then it will stay hidden until the field changes. If your manual hide/show happens before the initial value comes in (very likely in an OnPreload), then the initial value will just unhide it again if the field is non-zero.

And you don't want to do it in OnLoad, because then you'll see the widgets blink on and then back off again in most cases.

Soooo, I think that the appropriate thing to do is have the 'hide if zero' thing be completely separate from the widget hide/show, and just have the time text widget refuse to redraw if the value is zero, but otherwise leave the hide/show state alone, so that that is only something that changes if you manually set it yourself (or set the initially invisible check box on the Base tab of course, which just causes the initial visbility state to be hidden instead of visible.)

Does that make sense? It is a breaking change though. If you have initially hidden a time text, it won't show up now automatically once the field goes non-zero if you have the hide if zero option checked. You'll have to manually show it.

[SamVimes2]

if you're tooling around in there don't forget to think about how to implement some related enhancements (http://www.charmedquark.com/vb_forum/showthread.php?t=8850)

[Dean Roddey]

We are in 'no more than what has to be done' mode right now, so that we can get things solidified and get 3.1 out. That one was one of those that really just wouldn't work right as it was.

[jrlewis]

I'm on 3.0.25 and the ParseBuf method for the XMLTreeParser seems to have an issue. To test it I created a stripped down macro with the code below and I have also listed the error message from the log. The ParseFile method works just fine.

Method Start() Returns Int4
Begin

Locals=
Card4 i;
MemBuf Buffer;
String Test;
XMLTreeParser Parser;
EndLocals;

Try
Test := "<?xml version=\"1.0\" encoding=\"iso-8859-1\" ?><Root><Child>Child1</Child><Child>Child2</Child></Root>";
Buffer.ImportString(Test,Test.GetLength());
Parser.ParseBuf(Buffer,i);
EndTry;
Catch
Test := $Exception.GetErrorText();
EndCatch;

Return 0;

EndMethod;

CIDMacroEng, CIDMacroEng_MethodImpl.cpp.955, Status/App Status
An unknown exception was thrown from method MEng.System.Runtime.XMLTreeParser.ParseBuf

[Dean Roddey]

You never set 'i' did you?

[jrlewis]

No, but that is listed as an Out parameter. In the actual driver I did set it to the same size as the buffer data assuming maybe the Out was actually supposed to be an In parameter, but it still throws the error.

[Dean Roddey]

Definitely it's an in parameter, so I'll fix the docs there. I think I already have some tests for that that are working fine, but I'll look at it.

Oh, one thing is that I think it's required that there be a new line after the XMLDecl line, because that's examined separately and in a very basic way by XML parsers and used to figure out the encoding. You shouldn't get that particular error back, but change that and see if it makes a difference.

[jrlewis]

Added new line and set i equal to bytes encoded into the buffer from the Test string and it still doesn't jive.

[Dean Roddey]

OK, I see what's up with the buffer based XML parse. That'll be fixed in the next drop.

[jrlewis]

As long as I have your attention on the XML stuff is there any plans in the near future to add the needed methods to edit the XML in the parser and then get it back out into a string or a buffer.

[Dean Roddey]

That's not even supported in the underlying C++ version currently. It's a read only tree structure at this point.

[sic0048]

I'm running 3.0.26, so forgive me if this has changed in the latest beta. But I noticed that a Web Browser's "Set URL" command is only available in the OnPreLoad section of the templates action. I need to be able to set the URL in the OnLoad section of the template actions.

Here is my situation. I have a template that I use to show some historic graphs created by the Graphmatic program. I have several small web browsers on the page and need to set each one to a different jpg file. But I need to run the graphmatic program to update the jpg images before displaying them.

I can run the graphmatic program in the OnLoad section of the template's actions, but I cannot run it in the OnPreLoad. Likewise I cannot set the URLs after running the Graphmatic program in the OnLoad actions. So I am stuck.

The only other alternative is to have a button to manually set the URLs after the template is loaded, but that isn't really acceptable.

Thanks,

[Dean Roddey]

Yeh, it was only available in OnPreload because by the time OnLoad is running, it's already loading any originally set URL. But, if you don't have an original one, that wouldn't be a problem really.

[sic0048]

Is there a built in boarder when using the CQC Web Browser Widget? It seems that there is a border on the top and left side of the widget. It is perhaps 10 pts on the left and 14 points on top.

Here is an example where I am loading a PNG picture into the Web Browser. The two "Please Wait For Graphs to Load" screens are being loaded into a Web Widget. Ultimately when Dean adds the SetURL command to the OnLoad commands, it will load the graphs automatically. But there isn't anything in my HTML file that would cause these borders to show up (there is no HTML file :-)).

http://i185.photobucket.com/albums/x46/sic0048/WebWidgetError.png

Anyway, I've know that I've always had to tweak my HTML files to a different size than the web widget, and now I suspect it is becuase there is a border on two sides.

[Dean Roddey]

I'm not drawing one. So it's got to be something being done by the thing being loaded, which I assume is some ActiveX? You can still I think point the web widget at a local HTML file (via our web server) that just loads an HTML file that wraps whatever it is and supresses borders and whatnot.

[sic0048]

It only happens when loading a picture into the web browser (a PNG file in my situation). I've had to install ActiveX on that machine for a variety of things (like the animated radar). I guess the ActiveX be functioning even when calling a simple picture?

I guess it is easy to call the picture from a HTML file instead of calling it directly. I use some simply HTML files with my traffic and radar pages, so I have the basic outline to get rid of the borders, etc.

Is there a simple HTML code line that I should use to call the picture? (I just don't have much experience with HTML). Or is there a way to turn off the ActiveX when pulling these pictures - but leaving it on when pulling other content that requires it?

The other option is to obviously just work around the frames which is what I've been doing up until now.

[jkish]

It only happens when loading a picture into the web browser (a PNG file in my situation). I've had to install ActiveX on that machine for a variety of things (like the animated radar). I guess the ActiveX be functioning even when calling a simple picture?

I guess it is easy to call the picture from a HTML file instead of calling it directly. I use some simply HTML files with my traffic and radar pages, so I have the basic outline to get rid of the borders, etc.

Is there a simple HTML code line that I should use to call the picture? (I just don't have much experience with HTML). Or is there a way to turn off the ActiveX when pulling these pictures - but leaving it on when pulling other content that requires it?

The other option is to obviously just work around the frames which is what I've been doing up until now.

I have a general purpose html image page that lets you pass the image url, width and height in as parameters in the url.

See this post under the Artwork heading for the code: http://www.charmedquark.com/vb_forum/showpost.php?p=108227&postcount=2

[sic0048]

I have a general purpose html image page that lets you pass the image url, width and height in as parameters in the url.

See this post under the Artwork heading for the code: http://www.charmedquark.com/vb_forum/showpost.php?p=108227&postcount=2

Perfect! Thanks. However, the more I thought about it, the more I wondered if is this a situation that is better served by using the new Web Image Widget? I checked the beta docs, but didn't see that it was updated with the new widget yet, so I am not sure if it works displaying a .PNG image.

[sic0048]

Something else I noticed last night. If I close out the IV via the task manger application tab, it does not close out the CQCIV Process as well (whatever it is really called). So when I try to reopen the IV, it give me some sort of duplication error. If I close out the IV process using the task manger, then I can reopen the IV just fine.

I don't think it has always been like that. I sometimes have to close out the IV when I view something full screen without a minimize button located on the IV and I typically do this with the task manager.

I'm running 3.0.25 (I think) - definitely one of the later betas, but not the absolute latest.

[jkish]

Perfect! Thanks. However, the more I thought about it, the more I wondered if is this a situation that is better served by using the new Web Image Widget? I checked the beta docs, but didn't see that it was updated with the new widget yet, so I am not sure if it works displaying a .PNG image.

Pretty sure it will display .png images.

[VidaBox LLC]

I'm getting an error from the RIVA server. If I restart the CQC service, the RIVA server comes online before most of the drivers are ready. So on CQC restart, a an active RIVA client will lose its connection and continually try to reconnect. Eventually it does when the RIVA server is ready but some of the driver might not be ready. I happen to have some fieldreads on OnPreload for the initially loaded template and I get a fieldread error right off the bat. The fieldread that I have an issue on is for a couple of var driver field and it's something I can't really change as I'm reading default values for the interface to use (such as template title info, etc.). The only recourse in this case is to restart the device as RIVA is full screen and I don't provide a way to bump out of RIVA. I think this should be handle in a more gracefull way like IV does. I think the RIVA server should not accept connection until drivers are ready. I know this is a tough one as you will say that it's hard to determine when a driver is ready.

I could place a waitfordriver ready in the onpreload but I think this one will get a lot of people before they figure out what the issue is so it would be nice to try do something (delay the RIVA server a bit perhaps).

[Dean Roddey]

The regular IV has a /Delay option that could be added to the various RIVA clients. It could just display a 'Waiting for System Startup' type of message or something, then continue on with trying to log in once that timeout is done.

We definitely can't wait for drivers to be ready, since in order to figure out even what drivers you are trying to access you'd have to log in and try to load a template. If we tried to wait for all drivers to be ready, some driver you didn't care about could keep you from using the system.

[potts.mike]

Would it be possible for there to be an option on the toolbar widget that allows it to have no text?

[Dean Roddey]

Would it be possible for there to be an option on the toolbar widget that allows it to have no text?

I can put it on the list. Can't say when I'll be able to get to it though... You could set them both centered and just not enter any text, right?

[wuench]

I reduce the font and use periods...

[VidaBox LLC]

The regular IV has a /Delay option that could be added to the various RIVA clients. It could just display a 'Waiting for System Startup' type of message or something, then continue on with trying to log in once that timeout is done.

We definitely can't wait for drivers to be ready, since in order to figure out even what drivers you are trying to access you'd have to log in and try to load a template. If we tried to wait for all drivers to be ready, some driver you didn't care about could keep you from using the system.

Sorry Dean but this one needs to be handled somehow. The driver that is causing this error is a pretty basic one (var driver) so the RIVA server is coming online too fast. There are a million things you can do to catch 90% of the potential issues before they reach the client. Remember that the RIVA client is what the user is interacting with so if they see an error, they begin to wonder about the stability of the system. You also can't rely on the system designer catching the million different little things that can happen. This particular one will catch almost everybody and I'm willing to bet that they won't catch it until the customer complains about it sometime in the future.

I don't want to simply place a delay in the startup of the RIVA client because that means that it will always delay the startup regardless if the drivers are ready or not. This needs to be handled by the RIVA server somehow. I think there is something more fundamentally off here as the var drivers should be up very quickly after a CQC server restart and at the very least, the RIVA server should not come online until the var drivers are available. Those are pretty fundamental and there is almost no reason why they should not come online. Unless they are on a secondary server that is turned off or something, but even in that case you would know the host is offline and ignore those drivers (meaning, don't delay the startup of the RIVA server on their account).

[LesAuber]

I agree with Sergio on this one and it's something I've mentioned before in general. With the small size of your beta test group, in comparison to the possible hardware permutations (must be in the trillions), having one person have an issue isn't necessarily a one off but something potentially significant.

I end up being tech support for my mother's PC so can somewhat understand what his customers will think. It's either the computer is messed up again (can I have a hint?) or worse she'll try and tell me what needs fixed. Still working on just remember and show me what causes it not to work.

In the end it will be much the same. They won't care that a driver wasn't ready all they'll see is the system didn't work. Having some soft fault handling would be helpful. If the driver wasn't ready just have it check again in a couple seconds while continuing to load the rest. Same for a device. If it's not ready try the command again in a second or so instead of throwing up an error message and freaking them out.

This last would be handy for devices like my old PJ that couldn't be polled at startup. Couldn't do an if/then on the command because you couldn't check to see if it was ready to receive without bollixing up the works. Not sure yet if my new PJ will allow this or not. Have to try it. Very much a hassle sending a command to change input to soon and getting an error display when all that really should be done is resend a few times spaced out by a second or so before crying wolf. These should be handled like is done with polls instead of a hard pause.

[Dean Roddey]

I can certainly have the RIVA server delay for a while when it comes up.

[VidaBox LLC]

I can certainly have the RIVA server delay for a while when it comes up.

Are you going to try do something more scientific or are you just going to insert X delay after CQC service start?

[Dean Roddey]

Well, it's already waiting for some things to become available. All of them have to wait for the more core servers to become available before they can register themselves and continue booting up, so they know that things are on the way up. So a fairly short delay of five seconds after that would almost always be enough for any driver that's going to come online to do so. That's what the logic server does. Even if it did some more fancy wait, it wouldn't want to wait much longer than that anyway, and it's short enough that it isn't any sort of real burden relative to starting up a system.

[Dean Roddey]

BTW, for special needs where you need to wait for sure for some particular driver to be ready before moving forward in the viewer, the means are there these days for you to do something yourself that is fully integrated into your system.

You can start first on an empty template, which checks one or two drivers for being ready. If not, it can do a popup that says please wait, and just uses the OnTimeout to periodically check again until the drivers are available, and then exit the popup and the calling template can reload itself with the real base template.

That may always be the best thing to do in such a case, because no matter what we do, we can't have the RIVA server just refuse to start until every driver is online. In a large system drivers can be offline for legitimate purposes, and we can't stop other users who aren't dependent on that driver from being able to work.

Nor would we want to keep it from coming up for minutes while waiting for a driver before continuing, for the same reasons. If a driver hasn't come up with fivish seconds, it may not be coming up and it's best to just continue. If particular clients need particular drivers to be up before loading, it may just have to be a burden placed on those clients to check that, because the driver may just never come up for whatever reason and the RIVA server can't sit there forever denying service to everyone because of that.

I could provide an action command that will take a list of drivers and return true or false if they are ready or not, to make it easier to do such a popup.

[VidaBox LLC]

BTW, for special needs where you need to wait for sure for some particular driver to be ready before moving forward in the viewer, the means are there these days for you to do something yourself that is fully integrated into your system.

You can start first on an empty template, which checks one or two drivers for being ready. If not, it can do a popup that says please wait, and just uses the OnTimeout to periodically check again until the drivers are available, and then exit the popup and the calling template can reload itself with the real base template.

That may always be the best thing to do in such a case, because no matter what we do, we can't have the RIVA server just refuse to start until every driver is online. In a large system drivers can be offline for legitimate purposes, and we can't stop other users who aren't dependent on that driver from being able to work.

Nor would we want to keep it from coming up for minutes while waiting for a driver before continuing, for the same reasons. If a driver hasn't come up with fivish seconds, it may not be coming up and it's best to just continue. If particular clients need particular drivers to be up before loading, it may just have to be a burden placed on those clients to check that, because the driver may just never come up for whatever reason and the RIVA server can't sit there forever denying service to everyone because of that.

I could provide an action command that will take a list of drivers and return true or false if they are ready or not, to make it easier to do such a popup.

I understand what your saying and have thought of all the workarounds that could be implemented. I agree with you about what can be done on the IV side to be a bit more intelligent.

The issue I was raising was a pretty basic one with regards to var drivers and I hope the 5 second delay your proposing will take care of that. I really only want to do more complicated logic in case of specific device drivers that might be offline, but not for basic stuff like a var driver. Also, as we have more devices out to display CQC interfaces (tablets, iPhones, and NEVO remotes), the more complicated all this gets to keep track of. Ultimately, a logic change might have to be duplicated several times across several device templates. That can be very painful depending on what needs to be implemented. Time is money for our dealers as they are making a living off this product. They make no money squashing bugs in the programming.

Another thing you have to keep in mind Dean is that I'm always trying to eliminate a support call whenever possible. I'm a seasoned CQC programmer at this point and can easily implement what your talking about. But what about a beginner? Can I easily explain what you just laid out and have that person implement it without him calling me every five minutes? I think not and that's the issue. I think overall, this is too low level type stuff for a typical person to have to deal with. I think some basic logic on the server can really save a lot of headache for the programmer. Yes I agree it's complicated to implement, but the ultimate success of this product depends on ease of use. Anything you can do to head of a possible issue needs to be implemented even if it's a bit complicated to put together. I know how to create a workaround for most situations at this point but that doesn't mean my dealers can. That's why I bring them up.

So workarounds like you just described need to be avoided like the black plague. A more elegant solution should be put in place that I can easily explain to my dealer and have him implement it WITHOUT MY HELP or worse, me login-in and doing it for him because his customer is breathing down his neck and possibly threatening to have the system ripped out because "it's not working". Now the later will probably not be the result of this particular issue but this issue plus another 10 seemingly minor issues can lead to an implementation that in the end customers view is a buggy system. Now every customers bug threshold is different but everybody has a tipping point and I don't want this one to tip it to the "rip the sh*t out" point.

That's why I press you so hard on all this stuff because VidaBox has a lot more at stake dollars wise than a $2,100 CQC license (many times, $50K+ worth of equipment). Sorry to rant but that's why I'm hardcore on bugs and push to have better ways of doing things.

[Dean Roddey]

I definitely appreciate all of that. And I always do whatever I can to make things better. But some things are just of the 'rock and a hard place' type of issues, and this is kind of one of them. There's probably not an answer that doesn't require clients doing the chcking. It's not a monolithic system and therefore it's just impossible to make sure that X is up and running before Y in a lot of cases. Some things I just can't really make happen, no matter how much I'd like to help.

If you really wanted to keep it centralized, and perhaps this would fit into the other thing you and Mark were experimenting with, i.e. the 'uber driver', then you could do it there. Where the uber driver only comes online when everything it depends on is online, and then you have a single driver you can test for in the clients that won't have to ever change.

If that's not doable, I'm not sure what to do. I guess we could allow the RIVA server configuration to let you indicate one or two specific drivers it should wait to be available before coming online or something like that. But, if that driver never comes online for some reason (or is taken offline for some reason for a while), then the same issue applies, and would have to be dealt with on the client side because the RIVA server is already long since up and running.

Or, even if you don't do the uber driver, just a very dead simple driver that did nothing but come online when a desired set of other drivers comes online could be used as a means to have a single point of checking, and since it could poll those drivers in an ongoing way, a driver being taken offline after the fact would also be caught (except for a very short window of opportunity between when the src driver went offline and the magic driver saw that.)

[DaveB]

Dean - I stay quiet on much of this, but I agree with Sergio. Issues such as this has cost me $$ over the years. You need to not only look at the core product , but also at the end user experience. It is at that level that we all make money. The end user never appreciates or sees any of the the changes you make to ther product. All they care about is that when they press a screen button, the device acts accordingly.

[beelzerob]

Dunno if this is to blame for the beta, but....

I'm trying to use the smtp email thing, which Ive used before successfully. but now, so far, when I try to send out an email, I get:

Could not convert '+OK' to binary value of type 'tCIDLib::TCard4'

No idea what any of that means.

[Dean Roddey]

I assume that must be in a response, but I'd need the rest of the error info to have a better idea.

[Dean Roddey]

Dean - I stay quiet on much of this, but I agree with Sergio. Issues such as this has cost me $$ over the years. You need to not only look at the core product , but also at the end user experience. It is at that level that we all make money. The end user never appreciates or sees any of the the changes you make to ther product. All they care about is that when they press a screen button, the device acts accordingly.

The issue here isn't so much the end user experience. The tools are there to make the end user experience work correctly. It's how best to do it to minimize the middle-man effort I think that's the issue. There's no real 'solution' for this general issue, because it's just part of being in a distributed system where the system isn't just all up or all down, but can be in an intermediate state.

A couple of the options above would perhaps be a useful middle ground. I can add some configuration to the RIVA server that would make it wait for some set of drivers to come up, but that wouldn't help other than on system startup. It wouldn't help if a driver was down for some particular reason after the system is up and running.

The 'driver state assessing driver' type thing would probably be the best overall compromise. It keeps the configuration of what drivers are important in one place, it would keep the whole thing just a single check for a single field in the client(s), and it would work not just on system startup but also if any of the drivers were offline for some other reason after system startup. So that wouldn't be a bad way to deal with such a situation.

Though I guess the RIVA server configuration could be extended to not just keeping the RIVA server from coming up, but would return some specific failure indicator to the client so that the client wouldn't be able to log in but would know it's become of one of the configured required drivers not being available.

[sic0048]

Dean,

I'm running 3.0.28. I have a radar template that has a web widget in it. That widget is set to automatically load one of my flash radar HTML files. When I load that template, the radar still gets loaded twice - about 0.5 to 1 second apart. So you will see the radar image load, disappear, and then load again.

I suspect that whatever automatic load problem you found at the template level is also in the automatically load code of the widgets that allow it.

[VidaBox LLC]

I definitely appreciate all of that. And I always do whatever I can to make things better. But some things are just of the 'rock and a hard place' type of issues, and this is kind of one of them. There's probably not an answer that doesn't require clients doing the chcking. It's not a monolithic system and therefore it's just impossible to make sure that X is up and running before Y in a lot of cases. Some things I just can't really make happen, no matter how much I'd like to help.

If you really wanted to keep it centralized, and perhaps this would fit into the other thing you and Mark were experimenting with, i.e. the 'uber driver', then you could do it there. Where the uber driver only comes online when everything it depends on is online, and then you have a single driver you can test for in the clients that won't have to ever change.

If that's not doable, I'm not sure what to do. I guess we could allow the RIVA server configuration to let you indicate one or two specific drivers it should wait to be available before coming online or something like that. But, if that driver never comes online for some reason (or is taken offline for some reason for a while), then the same issue applies, and would have to be dealt with on the client side because the RIVA server is already long since up and running.

Or, even if you don't do the uber driver, just a very dead simple driver that did nothing but come online when a desired set of other drivers comes online could be used as a means to have a single point of checking, and since it could poll those drivers in an ongoing way, a driver being taken offline after the fact would also be caught (except for a very short window of opportunity between when the src driver went offline and the magic driver saw that.)

Again Dean, sorry for the rant. I know you care deeply about your product and try to do what's best all the time. I want you to know that we appreciate the attention you give to everything involved with your product. I want to make sure you know that since most of our conversations end being about stuff that might not be working or could be done different and end up not being the most fun of conversations most of the time.

The scenario I brought up is a very simple one and a common one. All the 3rd party devices are online and working. I reboot the CQC server. The RIVA clients disconnect and try to continually reconnect to the CQC server. The CQC server comes back online. The RIVA client connects but I get an error because the var driver the template needs is not online yet. This should not happen and I shouldn't have to do any special magic to get it to work. All devices are online and ready to be controlled. In that case, CQC should be smart enough to delay things and not allow a RIVA client to connect. I'm not saying we should wait till all drivers are up. Some may take a considerable amount of time such as a repo driver loading music from a large library. But there should be a best effort based type thing done so that in 90% of the cases, the RIVA clients would connect without an error and with no extra magic on the template programming end. I agree that it's impossible to do a 100% type thing. There are way too many things to work out and no solution would be very satisfactory.

So if you think adding an X second delay will bring us to the 90% working state, then I guess that's OK.

I'm guessing that your other suggestions would be post 3.1 type stuff. Whatever improvement that gets implemented needs to be easy to deploy and to teach/describe. That rules out CML drivers or command line type options for RIVA or IV. 99% of my dealers will never learn CML (nor do they want to). I guess the bigger picture problem is that when error windows pop-up,they look to the end user like something is majorly wrong with the system, because they don't look like the interface and generally doesn't tell the user anything about the error unless they click details. Even if they did click details, the info is written in English there but it might as well be written in Chinese.

On top of everything else we have been talking about, maybe there should be some thought on providing a way for errors to be trapped in IV and maybe in the event system and providing a mechanism for the designer to provide user friendly information about what might happening. So if an error get's generated from a field read/write then the designer can create a popup that says, "I can't read your music library, make sure your NAS is powered up" or "please wait a while, I'm indexing your music library". That's a million times better then what is currently coming up and I think would go a long way to making the end user experience much more gratifying (and less hostile since they know what's going on). I also think it's easier to program and to explain to dealers than trying to teach them other more complicated logic schemes. In the end, I think this would be a nice feature to add for all sorts of other issues such as loss of wireless connection on a tablet (that's the number one cause of user frustration as IV looks up and the user doesn't know why). But this is a discussion for another thread and really not related to this beta.

[Steve]

I debated getting in the middle of this but I just have to throw my quick thought into this. I really do appreciate everything Dean does to make this product as good as it is and I also appreciate guys like Sergio and VidaBox for pushing Dean and making it that much better. I know Dean has a long to-do list, some items of which have been on it literally for years and I know things are prioritized accordingly. That said, I think if there is a real simple solution to this great, but if it gets complicated, I would question its priority.

What I mean by that is it sounds like all of this is based on a RIVA client not behaving correctly if the CQC server reboots. So I guess my point is - how often is that realistically going to happen in a production system? And if a server reboots I think it would be realitic that the user knows something in the house went wrong as that should be a very rare occurrence in a system with a good server and UPS. So I would think it would be reasonable that a customer/end user knowing something happened in the house would try a few times to restart (or whatever depending on what the RIVA client was) the RIVA device if it glitched and if it was just a matter of some kind of delay, then the device should act normal again by the time they restart the device. And I would further assume that RIVA clients are limited anyway and most of the really important control devices are running the full IV anyway.

So I apologize if I misunderstood or misspoke but it just seems this should be a rather rare issue that should be addressed/prioritized later.

[beelzerob]

Uh...dunno where my post went...but I got the reply email notification.


I assume that must be in a response, but I'd need the rest of the error info to have a better idea


Not sure what you mean. What I posted is all there was. It was in red text and in the log. Oh...I guess you mean all those other little details that show up when you click on that log entry? Ok, I'll get those tonight.

[LesAuber]

The other place you can get a fault flashed on the screen for the user is if a device wasn't ready yet. Not all devices are well behaved enough to tell you when they're ready. Sending a command to, say, change input before the device is ready elicits a fault message blazing across the screen with something cryptic about some moniker failed to respond. The options are OK or Details.

I can pretty much guarantee that my parents, girl friends etc would simply tell me something to the effect of the $##$&(( is doing it again. The explanation of simply press OK and try again wouldn't be well accepted.

Things like this should be handled in the background gracefully. The same for missing drivers. Instead of sending a fault message handle it in the background. Have it resend the change input command that started this or try the reacquire the recalcitrant driver again in x seconds without halting the rest of the system. If CQC can't accomplish the desired action in Y tries then an error message is in order. This goes beyond just the RIVA client.

There are probably other soft type faults that should be handled in the background as much as possible. These two are the ones I've encountered. Not all need to displayed immediately or halt the system. They should be separated from hard faults like a server crashing as much as possible.

Yes, a macro could possibly be written to capture the fault and retry. But where and when it's needed can be a bit tricky to trace out. For the CI's it's time, for a mechanical type like me simply another headache I don't need.

And yes, I very much appreciate the effort Dean puts into this product from the unique perspective of having watched/used it almost from the beginning.

[Dean Roddey]

Definitely an 'OnError' event has been on the list for a long time. So that, if any error occured, the whole action stack would be unrolled back to the original action and, if it has any commands in its OnError event, those would be run. But it's just not been done yet. It's been on the 'definitely for the next release' list for a while now, but other things keep bumping it off. Actually, given all of the changes that occured wrt to supporting the RIVA system, it's maybe a good thing it was bumped, but now all that stuff is considerably cleaner and it would probably be reasonable to do now.

A CML macro is a way to do in the meantime if you are comfortable wth that. I've done two systems for customers back in the day before we had anyone else to do pro type solutions, and did them both completely that way and they are very stable systems that have been working fine for years without ever hearing anything from the customers.

So definitely having such a capability is very important. It can't always fix things, but just to display to the user a message that's very tightly integrated into the look and feel is a hugely useful thing, where the error message is something related to what they just tried to do, e.g. 'sorry the projector failed to turn on' or something like that, which gives them something that they can report to the designer of the system that makes immediate sense as to what needs to be looked at. Or, in many cases, it gives them sufficient info to just take care of it themselves.

[Dean Roddey]

I'll get a drop up today that adds a little bit of 'see what the state of the state is before coming online if possible' type of logic in it and we can see what that does for the situation before I put the blind delay in.

[LesAuber]

If the 'OnError' command could be a repeat the failed command x times, every y seconds for z times that would be perfect. Having the option to suppress certain messages would be a compliment to this.

Having an error message just for issuing a command to soon after power on doesn't seem necessary to me.

[Dean Roddey]

BTW, even now, for known special cases you can avoid this issue. The field read and write commands have a third pararameter that tells it whether it should fail, or just return a true/false indicator of whether it worked. So you can, short of a full scale OnError type thing, already do fault tolerant device I/O in those special cases where you know there can be iffy device response.

Even with the OnError that would sometimes be the easier and cleaner scenario. The OnError won't be able to repeat the action automatically. That would sometimes be very dangerous to do, since some of it could have worked, and that might cause it to happen more than once. It will generally be necessary for the person creating the logic to be responsible for deciding to re-try something.

[Dean Roddey]

So I updated the RIVA server, when it comes up, to wait for some drivers to show up, and then select a few of them and wait for them to come online. It'll go through this process for up to 15 seconds, then just continue.

This won't absolutely guarantee success, since the one driver you care about might not have come online. And, it could be an annoyance since the one driver you don't care about and know is not going to work will happen to be one of the one it selects, so it'll be a full 15 seconds (plus the other system startup time it requires to get itself up and do some other basic housekeeping chores) before it starts up.

But, it should generally always work. Particularly if your concern is about a variable driver, since they should be up if any drivers are up (assuming they are on the same CQCServer as one of the ones that the RIVA server kind of randomly chose to wait for.)

Later, we can update this to let you indicate which ones specifically you want to wait for. But, for now, this will almost certainly always insure that a system where all the drivers are on one machine will work correctly and the RIVA server won't come up too early. Even after it sees the (up to three) drivers come online, it still has to then register itself and the clients have to see this, etc... So there'll still be a bit more delay before the clients actually connect.

[Dean Roddey]

OK, I've tested this out and it appears to work well. I've started up the full smash of servers few times, a couple with a big compile going on, in order to put a heavy load on the machine, and the RIVA client (pre-started on auto-login so it's waiting) comes up with data fully intact. From the logs, with my fully simulator driver based testing system, the delay ends up being about 6 to 8 seconds, but this is a debug build which loads slower.

So it looks like this should take care of the problem. I'll get a new drop up in a bit.

[LesAuber]

BTW, even now, for known special cases you can avoid this issue. The field read and write commands have a third pararameter that tells it whether it should fail, or just return a true/false indicator of whether it worked. So you can, short of a full scale OnError type thing, already do fault tolerant device I/O in those special cases where you know there can be iffy device response.

Even with the OnError that would sometimes be the easier and cleaner scenario. The OnError won't be able to repeat the action automatically. That would sometimes be very dangerous to do, since some of it could have worked, and that might cause it to happen more than once. It will generally be necessary for the person creating the logic to be responsible for deciding to re-try something.

I'll give this a try. However, as to the danger remember the types of things I'm looking at, change input, resend a status to a driver etc. All rather benign things. When the read/write is set to not fail on a command does it actually return true/false or only when it fails or always? Does it retry if it fails? I'm just trying to make things a little more tolerant of impatience, not ignore something important.

[Dean Roddey]

It just returns true or false to indicate if it worked or not. If you'd like to retry it, you'd do something like:


If Not Devices::FieldWrite(Device.Field, value, False)
// Maybe pause for a couple seconds

// Then do it again before giving up

EndIf;


The second one could set some message text and return, and the calling action could display an error popup. The above could be put into a template level action so it could be invoked from multiple places by name.

[beelzerob]

Ok, here's the full details.

12/08 23:09:36-cqc-server, CQCEventSrv, CQCEventWorkerThread0
{
CIDLib, CIDLib_String.cpp.3596, Failed/Bad Parms, Error: 3263/0/0
Could not convert '+OK' to binary value of type 'tCIDLib::TCard4'
}

Here is the action doing the bad deed:

System::EMail
P1=GMAIL
P2=myemailaddress@yahoo.com
P3=yo
P4=it works

[LesAuber]

It just returns true or false to indicate if it worked or not. If you'd like to retry it, you'd do something like:


If Not Devices::FieldWrite(Device.Field, value, False)
// Maybe pause for a couple seconds

// Then do it again before giving up

EndIf;

The second one could set some message text and return, and the calling action could display an error popup. The above could be put into a template level action so it could be invoked from multiple places by name.

Ok, but I'd still prefer to only get a message if it fails completely on this type of thing. Don't really need to know that the command did what it was supposed to do but only when it doesn't.

[beelzerob]

I've another issue too,

12/09 16:44:34-cqc-server, CQCEventSrv, CQCEventWorkerThread3
{
CQCKit, CQCKit_ThisFacility.cpp.2543, Failed/Data Format, Error: 2009/0/0
'True' is not a valid field name. It must be in the form 'moniker.fldname'
}

resulting from this action.

If
System::Equals
P1=$(MSVars.UseTTS)
P2=True

Devices::FieldWrite
P1=TTS-CQCServer.SayText
P2=Garage workshop door
P3=True

End
If
System::IsNight

Devices::FieldWrite
P1=$(LightingControl.GarageDimmer_State)
P2=True
P3=True

End

[Dean Roddey]

I would have to assume that MSVars.UseTTS is set to the value 'True'. That's the only thing that makes any sense there.

[Dean Roddey]

Ok, but I'd still prefer to only get a message if it fails completely on this type of thing. Don't really need to know that the command did what it was supposed to do but only when it doesn't.

It would allow you to do that. It returns true if it worked, false if it doesn't. You can use the field read and write commands in an If or If Not statement depending on whether you care if it worked or didn't work.

[beelzerob]

I would have to assume that MSVars.UseTTS is set to the value 'True'. That's the only thing that makes any sense there.

Yes, it is. Other actions also use that flag, and do not give that error. I'll try removing that IF...

[Dean Roddey]

Ok, here's the full details.

12/08 23:09:36-cqc-server, CQCEventSrv, CQCEventWorkerThread0
{
CIDLib, CIDLib_String.cpp.3596, Failed/Bad Parms, Error: 3263/0/0
Could not convert '+OK' to binary value of type 'tCIDLib::TCard4'
}



It seems like Gmail is returning something in correct, or it's not really an SMTP account or some such thing. But without a dump of what it's returning there's no way to know. You can connect with a terminal program and do the simple set of commands that an SMTP client sends (they are just simple text commands) and see what it's returning.

Here is an example of such a conversation. When you connect, the server (S:) sends you an initial greeting, then you type HELO and your e-mail address and hit return, and it sends the next command so so forth.


S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: Alice Example <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}


You can see that there are OK's in there in various places, but it looks like perhaps a status code is missing, so the OK following it is being taken as a the satus code.

NOTE: To end a message put a period on a line by itself and hit enter. The server then accepts it and queues it up.

[beelzerob]

I removed the If statement, and I still get the error.

[Dean Roddey]

Oh, it's this:

P1=$(LightingControl.GarageDimmer_State)

You are using the value of the field and not the name, so the value of the field is True.

[beelzerob]

Doh! I must have used InsertToken instead of clicking on the notepad.

I'll make a small plea for errors that are more easily decipherable (like maybe including the line of offending text)....I'd be happy to resolve these problems myself without having to waste your time on it.

[beelzerob]

Well, could it have something to do with how I have smtp setup? Because I just recently reinstalled it, so I must have done something wrong. I know I'm not the only one who uses this for email, so I'd have thought someone else would have brought it up if it were an issue.

[Dean Roddey]

Doh! I must have used InsertToken instead of clicking on the notepad.

I'll make a small plea for errors that are more easily decipherable (like maybe including the line of offending text)....I'd be happy to resolve these problems myself without having to waste your time on it.

Unfortunately, what you did could be completely legitimate. You may use a field as an 'indirection' mechanism, so that you don't write directly to the field but to the field pointed to by the other field. So it's not really an error unless it happens to really be an error.

[Dean Roddey]

Well, could it have something to do with how I have smtp setup? Because I just recently reinstalled it, so I must have done something wrong. I know I'm not the only one who uses this for email, so I'd have thought someone else would have brought it up if it were an issue.

The e-mail stuff does work and lots of folks are using it. So I assume it has to be something specific to your setup there. That's why doing a manual interaction to see how it responds would be useful.

[DaveB]

The issue here isn't so much the end user experience. The tools are there to make the end user experience work correctly. It's how best to do it to minimize the middle-man effort I think that's the issue. There's no real 'solution' for this general issue, because it's just part of being in a distributed system where the system isn't just all up or all down, but can be in an intermediate state.

A couple of the options above would perhaps be a useful middle ground. I can add some configuration to the RIVA server that would make it wait for some set of drivers to come up, but that wouldn't help other than on system startup. It wouldn't help if a driver was down for some particular reason after the system is up and running.

The 'driver state assessing driver' type thing would probably be the best overall compromise. It keeps the configuration of what drivers are important in one place, it would keep the whole thing just a single check for a single field in the client(s), and it would work not just on system startup but also if any of the drivers were offline for some other reason after system startup. So that wouldn't be a bad way to deal with such a situation.

Though I guess the RIVA server configuration could be extended to not just keeping the RIVA server from coming up, but would return some specific failure indicator to the client so that the client wouldn't be able to log in but would know it's become of one of the configured required drivers not being available.

Dean;
This has everything to do with the end user. This is a end user bottem up problem, and my point that I was attempting to express to you is that you need to remove your self from the server end and place your self into the customers position. The server, drivers and connectivity, RIVA clients and full clients should always restart correctly every time. Every in warranty service call costs huge $$$ for everyone up the line.

Keep up the good work. I know you will find a middle ground solution.

[beelzerob]

So it's not really an error unless it happens to really be an error.

Well, I agree....but at some point, CQC knew it was an error, hence the message. At THAT point, it would have been helpful if it had wound back to the action and somehow indicated the line...because I also was hung up on the UseTTS call, having nothing else to indicate where the error was but the "True"

[beelzerob]

Well, I took one more stab at the stunnel.conf file, and now it works!! :roll:

[Dean Roddey]

Dean;
This has everything to do with the end user. This is a end user bottem up problem, and my point that I was attempting to express to you is that you need to remove your self from the server end and place your self into the customers position. The server, drivers and connectivity, RIVA clients and full clients should always restart correctly every time. Every in warranty service call costs huge $$$ for everyone up the line.

Keep up the good work. I know you will find a middle ground solution.

Yeh, obviously it's an end user issue if it doesn't work. The point was that there are tools there now for the installer to take care of this particular issue for the end user in a way that's well integrated with their solution. What was being discussed was the addition of some other things that might make it easier for the installer to do that in specific circumstances.

But, ultimately, it cannot be guaranteed that every device required will be up and running at the point where a client starts up. This is just the nature of the beast because we are interacting with devices outside of our control. There's zero we can do about that. So, if a client specifically needs a device to be available before they even start up, sometimes that's just going to have to be dealt with with logic in the client.

The IV itself (and by extension the RIVA clients) always will work correctly in and of themselves. They are designed to be tolerant of devices not being available and reconnecting to them as required.

But we obviously can't do that for user written logic. To some degree the person creating the logic on the client will have to deal with device communcations failures because they can happen at any time.

Definitely the OnError thing is currently the missing ingredient in this soup, so hopefully we can get that into the next release.

[Dean Roddey]

Well, I took one more stab at the stunnel.conf file, and now it works!! :roll:

I assume you had our e-mail client talking directly to stunnel, or we weren't going through stunnel and were therefore seeing protocol stuff that's related to the setting up of the encrypted session from gmail.

[beelzerob]

Did SendEmail move from CQCUtils? I get a method not found compile error.

Also, the docs for CQCFldDef are missing stuff...I took a leap that there was a GetType and GetAccess, and was rewarded.

Finally, in the macro workshop, when stepping through, I try to watch the values of the local variables. To do that, I have to select the variable. But then when I step (F11), it goes back to the top of the local variables list. Very annoying. Could you fix it so that it stays on the variable you selected, so you can actually step through and keep monitoring the same variable without having to reselect it every step? I don't seem to recall the driver harness having this issue, but maybe I never noticed.

[Dean Roddey]

In case that was a typo, it's SendEMail() with a big M, and there's a SendHTMLEMail(). I think I got the field def class in the beta docs which will be the real docs before too much longer, but I'll check it again just in case.

[beelzerob]

Dean, is there a CML call somewhere to see if a driver is online? Or do I just have to use try/catch?

[sic0048]

Dean,

I'm running 3.0.28. I have a radar template that has a web widget in it. That widget is set to automatically load one of my flash radar HTML files. When I load that template, the radar still gets loaded twice - about 0.5 to 1 second apart. So you will see the radar image load, disappear, and then load again.

I suspect that whatever automatic load problem you found at the template level is also in the automatically load code of the widgets that allow it.

Not to be a pest, but I wanted to make sure you saw my post - it was in the middle of the heated debate. :-)

[Dean Roddey]

Dean, is there a CML call somewhere to see if a driver is online? Or do I just have to use try/catch?

Yeh, your best bet is to try to read one of the special statistics fields that every driver has and catch the error.

[Dean Roddey]

Not to be a pest, but I wanted to make sure you saw my post - it was in the middle of the heated debate. :-)

Yeh, I did miss that. I fixed the other thing, so it would have to be something to do with the web widget itself I guess. I'll look at it. Just to be sure, you don't have it both in the OnPreload and OnLoad now or something do you?

[beelzerob]

One more question, and then you can get back to your argument....

Is there a limit to the size of a string that can be passed out of a macro and into an action, and then expanded as the message of a SendEMail system call?

I ask because I'm trying to send out a pretty hefty string, and I'm getting:

12/09 23:32:01-cqc-server, CQCEventSrv, CQCEventWorkerThread0
{
CQCKit, CQCKit_ThisFacility.cpp.528, Failed/Data Format, Error: 6257/0/0
Token expansion failed during command processing
}

I called the macro, passing in the LVar I had created (by name), and then I try to use that LVar as the msg part of the email (by reference). And that statement is where the error occurs.

System::EMail
P1=GMAIL
P2=myemail@yahoo.com
P3=House Status
P4=%(LVar:statusMsg)

I made sure the LVar was created as a String too. And the macro doesn't complain about having it passed in. The parameter is an InOut (it was just Out, but it wasnt working, so I tried this).

Oh, and here is a rough example of the string I'm trying to pass out. It worked ONCE, whether directly from the macro, or from the action, Im not sure....

[Dean Roddey]

The token expansion thing would mean that there's some info in the message that looks enough like a replacement token that it's being interpreted as such but it's not a valid one. What is in the text you are sending?

Or, you could do this instead for P4=

%(LVar:statusMsg, "^1")

That should prevent the expanded text of the variable from being processed as it normally would.

[beelzerob]

Sweet, that works. Thanks! Now I'm getting way more info that I need, via email!!

[sic0048]

Yeh, I did miss that. I fixed the other thing, so it would have to be something to do with the web widget itself I guess. I'll look at it. Just to be sure, you don't have it both in the OnPreload and OnLoad now or something do you?

No. The only place the URL is set is in the web widget itself and it is check to automatically load. It is not in the OnLoad or OnPreload of the parent template. I just double checked to make sure.

[pseigler]

Currently, we have a situation where numerous touch-screens are peppered around a location...these screens "timeout" after x minutes of inactivity by revealing a full-screen image of a canned image. When the image is tapped, a template of a keypad is displayed where a user can type in their code to "unlock" the screen, which simply hides the image to reveal the main templates below.

there are a number of issues related to this process, not going to list them here, but would it be possible to include the following features:


(i) allow the blanker to accept an image from the CQC image repository to paint as the background, instead of a solid color.

(ii) allow the blanker to be released via an Action or Trigger through a template

(iii) allow a user to set a template to popup in front of the blanker on a mouse or touch event, instead to just hiding the blanker control when a mouse event fired. – this would allow a person to popup a template, i.e. “keypad”, or anything else... and only release the blanker via action. this would provide a lot flexability, including giving folks the ability to do things via the screen while it's blanked - say a nanny or someone needs to see a very easy template that can arm a house, or see a log of something...not to meantion open the doors for the deployment of multiple security consoles using the same CQC system.

[Dean Roddey]

We can look into some of those things after 3.1.

[Dean Roddey]

Sergio, did you get a chance to try out my potetial solution for your problem?

[VidaBox LLC]

Sergio, did you get a chance to try out my potetial solution for your problem?

Sorry Dean! Not yet. I should get to it later today or Monday.

[VidaBox LLC]

Another minor bug. I have a static text widget with text that wraps to two lines. I have a drop show effect on the font and have the text left justify. The first line of text is correctly justified to the left. However, the second line of text is not left justified. If I take the drop shadow effect off, the text left justifies correctly.

[Dean Roddey]

OK, I'll look at that. They use different underlying methods based on whether you allow text wrap or not, so that's likely the difference.

[beelzerob]

The "sorry" IV failure happened again:

CIDLib Kernel Runtime Error
Interface Template Viewer[MainView]
Error Info:
App: CQCIntfView
Module/Line: CIDWnd_Window2.cpp.319
CidLib error: 0 Kernel Error: 0

Error text:
An unhandled exception of unknown type was thrown by GUI code. The app will exit now for safety purposes. Sorry.

I'm on 3.0.27.

There are errorinf files in the logs dir, but they're from 36 hours ago, and don't appear to be for the interface viewer.

[Dean Roddey]

What were you doing at the time? This is some sort of null pointer dereference or something, I would think given the lack o' other info. But without some context I'm not going to be able to make any headway figuring it out.

[jkish]

I have this happen on a regular basis so it should be easy to repro.

Just copy a nice sized chunk to the clipboard in the action editor and paste/cut for a while and whooosh, the app blows away (along with all of your work). I save often these days because it has bitten me so many times.

[beelzerob]

Invariably, this happens sometime during the night. I only ever find these in the morning when I go to check the weather or some sort. So, I'm not doing anything to it at the time, so far as I know it's just sitting there.

[Dean Roddey]

Invariably, this happens sometime during the night. I only ever find these in the morning when I go to check the weather or some sort. So, I'm not doing anything to it at the time, so far as I know it's just sitting there.

Are you leaving a template up with at web browser widget in it by any chance?

[beelzerob]

Why, so I am! We leave our weather page up.

[Dean Roddey]

I have suspicions that the web browser actually never cleans up any memory and that it eventually just eats it all up. I think that, when it's used within the IE browser program that maybe it just periodically flushes the memory or something like that. It would be interesting to see what the memory usage of the IV is after running with the weather thing up all night, as compared to what it was the night before.

[beelzerob]

I'l try to remember to give it a look see.

[kayemsi]

If you periodically reload the template / overlay that contains the weather web widget, will that clear up the memory? Not sure how best to do the periodic reload of a template/overlay.

[Dean Roddey]

I'm not sure if it does or not. It may not. Some stuff I've read leads me to believe that it just never cleans up after itself and the containing app may have to flush that memory. But I don't know if that's really true or not.

[VidaBox LLC]

Just tried .29 and the RIVA client came online after a restart without an error. I haven't extensively tested it but it think it should be fine now for most cases. The cases it doesn't catch, can be handled by the programmer at that point. Thanks Dean!

[Dean Roddey]

Kewl... I'm working on the left justified (and it would have happend with right as well I tink) f/x text thing. It turned out not to be an easy thing, because of the complexity of the f/x text drawing method. But I got almost working yesterday and I'll finish it up today. There may be a resulting slight shift the position of f/x text because the originally never really quite worked correctly in terms of making sure the blur wasn't clipped in the case of offsets being applied and such. But I think it shouldn't be enough to really require any adjustment or anything.

[VidaBox LLC]

So, I'm trying to make my default template a little be more intelligent which is always a dangerous thing. What I'm doing is that I'm checking for status of various things and drivers in the onload of the template before I load a particular template into an overlay. I have an initialy loaded template in the overlay that says something like, "please wait...". Then once I'm done with the onload stuff, I change it to the template I'm interested in. So if I reload the template in IV, everything gets drawn on screen and eventually "Please wait..." gets replaced with the new template. However, if I start IV cold, nothing gets rendered onscreen until OnLoad is finished which kind of defeated the purpose. It might not be an easy thing to fix but can anything be done about that?

[Dean Roddey]

You could move that processing to a timeout based event. So in the onpreload set up a timeout for like 2 seconds or something (not activity based of course) and just go ahead and display please wait. Then when the timeout comes in, everything will have been drawn, you can disable the timeout first thing in the event, then do whatever you were previously doing in the OnLoad.