4.6 Official Beta Discussions Thread

[rtarver]

Dean,

Don't feel bad. I'm a native Texan and I have this obsession with mowing my grass with an old style push reel mower. I have to mow before 10am, otherwise I can't finish before giving up. Although, I do have the motivation of looking forward to a cool down in the pool to keep me going.

Russ

[DaveB]

Dean - I decided top kick the tires of the latest beta and the auto gen functions. I have an issue;

When trying to autogenerate, the generator is stopping as below. I can generate without images, so there must be an image reference incorrect or an image is missing. It bombs after the "misc" items generation. See below

You should also allow the autogen pop up to be scaleable or fix the bottom slider of the existing pop up.





Also, storage is cheap - "Your file of 63.0 KB bytes exceeds the forum's limit of 39.1 KB for this filetype." - Really

You should allow posting of screen shots without the need for third party services.

[Dean Roddey]

You must have a zero sized image and it's not dealing with that. It gets to the point where it needs to read in the data and the size is zero and it tries to create a memory buffer of that size, which isn't legal.

I'll take care of that.

[DaveB]

Thanks for taking a look.

[Dean Roddey]

I already fixed that, so it will be in the next drop. Probably not today, but maybe tomorrow. In the meantime, I bet if you did a directory of the images, sorted by size, you would find the empty one (or ones) because they would be smallest ones and first (or last) in the list.

[DaveB]

You are talking about the system directory, correct?

[Dean Roddey]

Oh, wait, nevermind. I was thinking about media repo stuff, but this is image repo images. It must be the \System\Empty image that is doing it. I must have added a reference to it in the last drop or so when tweaking, else I would have hit this issue already. I thought that guy was 1x1, but it must be 0x0 instead.

[Dean Roddey]

Well, actually it is 1x1, so it can't be that guy. Anyway, whichever image it is, the memory buffer object just tweaks the zero to one if asked to create a zero sized buffer, so an empty image won't cause an issue either way now. But I'll do some regeneration testing just to make sure, and put a break point there to see what is calling it with zero size.

[Dean Roddey]

Since we are getting well into implementing the "V2 Vision" (yes our marketing department came up with that), and it's not going to be practical to go through drivers by eye to validate them, or as now (when we are still making some tweaks to the device classes) to insure that all existing drivers have been tweaked, I'm working on the V2 validation for the driver IDE. I've got the XML file format, updated the image builder to copy them over, the data server to serve up the files, and a new class to parse the XML out for use at runtime, and I'm at the point of updating the IDE to use the stuff to do the validation.

I'll do that tomorrow and get it going. I've only got a few XML files done so far. Once I'm sure it's working and the format is right and whatnot, I'll start doing the rest of them. Not all of them may get into the next drop, but the most commonly used ones will, and I'll get the rest in the one after that probably.

I'm also going to go ahead I guess and make the changes discussed over in the Device Classification section related to power management. I've added the Devices::SetV2Power() action command to make that easier to do. And I'll add the other IV level version of that as well.

Also, I've updated the CommResults enum type, which drivers return to indicate the status of some calls, in this case particularly the field write callbacks where they handle writes to field. Currently, if a field write is rejected, the only thing the driver can return is that it rejected it. But I've added a number of broad but useful returns that they drivers can use now to indicate more specifically why the field write failed.

I've gone through the C++ drivers and made use of those where it's obvious what should be done, which is almost all such returns. The CML drivers will adopt them over time as time and opportunity allow. Obviously any new or reworked (to V2 standard) drivers can make use of them after the next drop.

This should help a lot on the in the field problem diagnosis. The old ValueRejected value is there still of course, for backwards compatibility or just something that doesn't fit in any existing category. But generally one of the new ones can always be used.

It's vaguely possibly that, if a driver is internally calling its own field write callbacks and checking for the ValueRejected result, then it will have to be updated since now it can be something else. This is not very likely, but possible and will need to be kept an eye out for. It would think that a failure actually worked.

[Dean Roddey]

Well, I clearly should have done this validation stuff sooner. The very first driver I brought up caught the fact that the standard media renderer base class was spelling the AUD#AdjustVolume as AUD#AdjVolume. Sigh... I had to change it to make it right. Hopefully, given the ability to directly set the volume, not many uses of it are out there. It'll be in the change list in red to indicate it's possible breaking change.

I still have some tweaking to do, but basically the validation stuff is there now for CML drivers. I'll start writing up the device class XML files and validating existing drivers. I need to get it implemented within my little C++ driver test harness as well so that I can validate those. That's partly why I'm not quite done, since I moved the core bits of it down lower in the code base so that it would be available there as well. And it required some new functionality to be added, which (being down low in the code base) required a lot of rebuilding.