Bug Report

[tmoulder]

Here is a list of bugs I've noticed using the software.  Apologies in advance if any of these have already been reported, appreciation if they have been or are being squashed

1.  3-D option doesn't stick.  I prefer basic lines to the 3-d style, but when I set my preferences, save, exit, and re-open, it's right back to 3-d.  Additionally, it would be nice to set an option to set all the code blocks to one or the other, rather than changing each one individually.

2.  In element selector, unticking the "Show system nicknames" box is not remembered when I re-start the software (essentially, any option should be retained).  Additionally, when looking at user tags, if I click on X0-X2047, I would expect the nickname list it to restrict itself to anything with an X input for an address.  I thought this was how it worked, but as I've added nicknames, it's not the case.  This may not be a bug at all, but I kind of thought it was the point of having the memory address ranges there.

I'll add more as I encounter them.

Thanks!

TM

[BobO]

1.  3-D option doesn't stick.  I prefer basic lines to the 3-d style, but when I set my preferences, save, exit, and re-open, it's right back to 3-d.  Additionally, it would be nice to set an option to set all the code blocks to one or the other, rather than changing each one individually.

In the options dialog, note the "Apply options to:" at the top. You need to check "New Views".

2.  In element selector, unticking the "Show system nicknames" box is not remembered when I re-start the software (essentially, any option should be retained). 

I'd say we could make it sticky. OTOH, it has been this way it is for 19 years...and as far as I am aware, you are the first person to ask.

Additionally, when looking at user tags, if I click on X0-X2047, I would expect the nickname list it to restrict itself to anything with an X input for an address.  I thought this was how it worked, but as I've added nicknames, it's not the case.  This may not be a bug at all, but I kind of thought it was the point of having the memory address ranges there.

The purpose of the Element Browser is to list all things that are valid for the current field. The Ranges and Nicknames lists are not hierarchical, they are orthogonal. Which is not to say that a hierarchical listing isn't a useful thing...but...as with the nickname filters previously mentioned, it has been this way for 19 years. Changing it might result in a few of our 50k users expressing discontent.

I am certainly game for improvements however, and based on your prior comments about the browser, we are planning to re-visit this in a future version.

[mhw]

The purpose of the Element Browser is to list all things that are valid for the current field. The Ranges and Nicknames lists are not hierarchical, they are orthogonal. Which is not to say that a hierarchical listing isn't a useful thing...but...as with the nickname filters previously mentioned, it has been this way for 19 years. Changing it might result in a few of our 50k users expressing discontent.

I am one of the 50K and I would be happy to see a change. Sometimes it is hard to remember if a tag name is an input or an output. Being able to narrow the list would be helpful.

[BobO]

Well, after thinking about it, I can easily justify adding another filter to it. Something like "Filter Selected Range". It fits the current metaphor, leaves the current behavior available, and gives the option of a hierarchical view. And it should be pretty easy too. Win for everyone.

As for the 19 year/50k thing...I'm mostly joking...kinda. When we started Do-more, we made a few changes that we thought were pretty small. Small things that ended up annoying the crap out of long term users. Since that time, we have become much more careful about making such changes. We're not opposed, just trying not to annoy some while helping others.

[Mike Nash]

I know this is an old topic, but the title says it all so I thought it might be appropriate.

Anyway, a (Find and) Replace on N101:7 with N201:7 will give an error where the element is used in a DELTA Contact:

Code: [Select]

[Error] $Main@67 ANDDLT: Parameter 1 (N201:7) is invalid: Element is an excluded size
But I can manually replace it. It works exactly as it should, but Replace won't replace it.

[BobO]

I know this is an old topic, but the title says it all so I thought it might be appropriate.

Anyway, a (Find and) Replace on N101:7 with N201:7 will give an error where the element is used in a DELTA Contact:

Code: [Select]

[Error] $Main@67 ANDDLT: Parameter 1 (N201:7) is invalid: Element is an excluded size
But I can manually replace it. It works exactly as it should, but Replace won't replace it.

Hmmm...it does indeed fail. We'll fix it.

[franji1]

Fixed.

Similar issue when replacing bits within Relational Contacts (luckily, bits inside Relational Contacts are more rare).  This bug was introduced in 1.3 when the Replace logic started performing better "Validation" of the replaced parameters.  It appears that the low-level Delta and Relational instructions did not like "bits", but the higher level "Editor" validation was fine with it.  So I "adjusted" the lower level instructions' validation.

So DmD 1.0, 1.1, and 1.2 do not have THIS specific Replace issue (although they have other Replace issues that 1.3 addressed).

So as a work around in 1.3, do the Replace, and when it lists any of these failures in the Output Window, just double-click on each failed replace and manually replace the elements via the Delta Contact and Relational Contact editors.