OI 7.11 Msg breaks with ENG0024, msg line1 divide by zero. This occurs when doing a gas guage. Try the following code. Interestingly enough if you change the value of field 23 it can work.

declare function msg

MsgMap='

MsgMap=Processing…"

MsgMap=Space(80)

MsgMap=G"

MsgMap=34

MsgUp=Msg(@window,MsgMap)

call msg(@window,msgup)

Actually if you place this in a loop it appears that if field 23 is in the range of 30 to 42 it errors. Outside of this range appears ok.

Very weird!

John

Thanks John. Fix will be in 7.1.2. In the meanwhile, try using GC instead of G as your message type or if your record count is in that range bump it up past 43 until the fix is available in the next release.

Bill

Any way I could get an RDK with the fix? If not how long until 7.12? I really don't want to re-engineer all my code…

Thanks,

John

John -

Best estimate on 7.1.2 release date is October 1,2005.

Bill

]] Best estimate on 7.1.2 release date is October 1,2005. «

I thought that this was meant to be a release that fixed bugs, how the heck can it be estimated to take that long?

If I told my customers to wait that long for a bug fix I would expect them to start looking at my competition.

Maybe you need to release 7.1.1.1 that just fixes some bugs.

Yep, we hit this same problem as well. Couldn't figure out why it "bombed" in some program and not in others.

We started stripping out the "unreliable" Msg stuff (when found), but it would be preferred if a fix was available as in 7.1.1.1

The sooner the better .

Thanks,

Ray

You know, sometimes it's hard to win here.

We get complaints that we do too many releases in a year, and now we get some that there are not enough.

We say we're putting out a release to handle bugs, bug then we get calls that some bugs are too important and must be addressed now, and then we get calls that a certain bug was not fixed in the bug release.

We're going to release an RDK for the MSG issue, but I hope that you all understand the kind of pressure, feedback, requests, and choices we have to make.

Thanks-

Mike

Mike,

I know the feeling. The "no win" scenario.

This isn't a perfect solution, but something that might come close is being willing to post patches to specific problems as soon as they have been reasonably tested (like you are doing with the Gas Guage issue). These would be offered "as is" and they would not modify the version of OpenInsight that they are being applied to.

Eventually, however, these would be officially included in the next version upgrade. Since the Works Downloads section can be sorted by date, it should be easy to note which downloads are "between version" fixes and those which are official releases.

You may find that releasing patch fixes will also cut down on the beta cycle time since people will had the opportunity to test some of the newer development before the beta releases are available.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Good idea, Microsoft do this all the time; they just a add a caveat that it has not been fully regression tested.

with customers like me .. who would want to be a boss

The only difference i can see is some are fixes .. not enhancements. When the message breaks .. that is a fix. When can't print .. that is a bug and needs fix .. when dicts keep locking up .. yep .. fix.

But those other cool things you are doing back in the dungeon .. those are enhancments and should be kept for a yearly update .. well unless i asked for them

do what you need to keep your sanity

dsig

View this thread on the Works forum...