Is this freeware or shareware or something?

Are you using the same config options in 0.70 that you were using in 0.65?

Does using sets core to auto and cycles to auto whereas in 0.65 core is set to normal and cycles to 3000.

My automenu dosen't seem to do that in 0.70 😖

Hi everybody

Hmmm.. let's see.

Is this freeware or shareware or something?

Interesting question. In all honestly I'm not sure now. A quick review on the Internet shows that version 5.0 is now available and is sold commercially. Version 4.7 is shareware and was the last shareware release in fact.

Are you using the same config options in 0.70 that you were using in 0.65?

Does using sets core to auto and cycles to auto whereas in 0.65 core is set to normal and cycles to 3000.

I did try the same crafted configuration I used for 0.65+CVS as well as creating a new one out of the 0.70 template. It made no difference. I'm preset the core to normal and the cycles to 3000 anyway in the configuration file.

The one obvious change between my previous CVS version and 0.70 was the introduction of keyboard layouts. I believe this may have something to do with the problem, even though I have mine set to none.

My automenu dosen't seem to do that in 0.70

That's interesting. What version are you using?

I should add for all those interested that there is a Automenu compatible menu system called RVMS available as freeware. It's not as good as Automenu, but provides a free option which is menu file compatible. It does not suffer from this keyboard problem, although I believe it may have new bugs instead 😀

I believe this may have something to do with the problem

Erm... no.

Pan wrote:

My automenu dosen't seem to do that in 0.70

That's interesting. What version are you using?

4.7

Hmm, that's very odd. Can you give me an idea of what configuration settings you are using on startup for the program? Remember that it only seems to happen if you run it from the configuration file.

After a little more testing, I still have the same problem. I have concluded the following:

* Automenu works perfectly under the CVS version of Dosbox taken as of the 9th of September, 2006 and the original 0.65 version.

* Automenu does not work without this issue under 0.70 or the current CVS release.

* It is not an OS issue. The same thing happens under Windows and Linux.

* The problem is not with my copy of Automenu. I downloaded another copy from the following site and the same thing happens.

http://www.bookcase.com/library/software/msdo … undef.menu.html

* The problem does not relate to the menu code I've written. The issue occurs even with the default configuration.

* Using the original Dosbox configuration or the custom one I've created makes no difference at all as long as the program is referred in there.

After a little more testing, I have a new theory and I do strongly suspect there is a bizarre bug in the keyboard interface. I know you don't agree WD, but the dismissive negative response you gave was not at all helpful when the evidence does lead more strongly that way than any other. The very link between the appearance of the new keyboard layout code in Dosbox and this issue indicates that alone.

I can confirm the following:

* If you run the Automenu program from the configuration file, the bug appears. If you exit and reload it, the problem disappears completely.

* If you remove the actual program execution from the configuration file, but still allow it to switch to the program directory, running "auto" manually from the command-line still results in the same problem.

* If you do the same thing however and enter "cd ." before entering a second command "auto", it works perfectly.

I think there is a problem with the carriage return in there somewhere, although I can't see how this causes the scrolling issue.

The very link between the appearance of the new keyboard layout code in Dosbox and this issue indicates that alone.

Well then remove it, try again and see that it doesn't have any effect.
If you know what's causing the problems, why are you asking here?

Well then remove it, try again and see that it doesn't have any effect.

Easier said than done. I'm not a C/C++ programmer 😀

If you know what's causing the problems, why are you asking here?

I don't really know what the problem is. I'm merely suggesting that the evidence points to some sort of bizarre keyboard input bug in the newly introduced keyboard mapping code.

Why am I asking here? For the following reasons

1) To see if anybody else has encountered this problem

2) To see if anybody knows any resolutions I'm not aware of.

3) To report and discuss the issue in general

I'm merely suggesting that the evidence points to some sort of bizarre
keyboard input bug in the newly introduced keyboard mapping code.

And why exactly? Just because "keyboard" is in your problem and
"keyboard" is in the cvs log? In what way is this helpful then?
Btw. keyboard mapping!=keyboard layout.

So screw that idea and get serious about posting helpful comments:
- work through the troubleshoot section of the readme
- try it on a different PC to be sure it isn't a usage mistake

And be sure you are using ONLY default settings, that is install dosbox,
DON'T change anything, start it, mount the drives and test the prog.

I know you don't agree WD, but the dismissive negative response
you gave was not at all helpful when the evidence does lead more strongly
that way than any other

Yeeeeeeehaw, evidence!

And why exactly? Just because "keyboard" is in your problem and "keyboard" is in the cvs log? In what way is this helpful then? Btw. keyboard mapping!=keyboard layout.

I'm aware of that. But you've got to admit that the sudden appearance of this issue along with the new keyboard mapping code suggests a possible link even if it isn't evidence. After all, the keyboard input routines aren't like the CPU core code, which is extremely complex and changes quite frequently. A fairly substantial development of the keyboard code along with the occurrence of this issue seems a bit suspicious to me.

- work through the troubleshoot section of the readme

And what suggestion displayed there do you think has any hope of resolving this problem? None of the suggested problems even slightly matched this issue. I'm not completely clueless you know. In the old days, I used to run DOS as my main OS.

I attempted it anyway because I know you would never be convinced otherwise. I even tried the stupidly unrelated ones like changing the memory settings in order to resolve a keyboard problem. But it made no difference anyway.

- try it on a different PC to be sure it isn't a usage mistake

I have to admit this was a sensible suggestion that hadn't occurred to me. I gave it a try anyway and the same problem occurred on the second PC.

And be sure you are using ONLY default settings, that is install dosbox, DON'T change anything, start it, mount the drives and test the prog.

Had you taken the time to read my previous posts on this thread, you would of realized that I've already covered this. But I've re-pasted the information below for you.

* Using the original Dosbox configuration or the custom one I've created makes no difference at all as long as the program is referred in there.

I can confirm the following:

* If you run the Automenu program from the configuration file, the bug appears. If you exit and reload it, the problem disappears completely.

* If you remove the actual program execution from the configuration file, but still allow it to switch to the program directory, running "auto" manually from the command-line still results in the same problem.

* If you do the same thing however and enter "cd ." before entering a second command "auto", it works perfectly.

I think there is a problem with the carriage return in there somewhere, although I can't see how this causes the scrolling issue.

Apparently hitting escape twice 'stops' the freakout

But you've got to admit that the sudden appearance of this issue
along with the new keyboard mapping code suggests a possible link even
if it isn't evidence

No, why should it? I don't have a clue what you want by that,
shall we look through the layout code now for weeks just to
finally find out that um... it's disabled?
If you have something like "it works at cvs date 9/9/06 but doesn't
at 7/7/06" that's a start. But not "hey keyboard problem->cvs log
has somewhere keyboard layout->evidence". Leave it out. Or debug
it yourself.

None of the suggested problems even slightly matched this issue

Several do. Just because "keyboard" isn't in there doesn't mean it
has an effect.

I even tried the stupidly unrelated ones like changing the memory
settings in order to resolve a keyboard problem.

Which isn't stupid as it (loadfix or whatever you mean) can of course have
an effect on keyboard handling by moving segments thus avoiding some
program bugs.
So spare your judgement here as well, if you know it better there's no
need to post as you surely can fix it yourself.

No, why should it? I don't have a clue what you want by that, shall we look through the layout code now for weeks just to finall […]
Show full quote

No, why should it? I don't have a clue what you want by that, shall we look through the layout code now for weeks just to
finally find out that um... it's disabled?
If you have something like "it works at cvs date 9/9/06 but doesn't
at 7/7/06" that's a start. But not "hey keyboard problem->cvs log
has somewhere keyboard layout->evidence". Leave it out. Or debug it yourself.

I resent that comment frankly. Of course I'm not asking for intense debugging sessions to take place over the limited information I've provided. In fact, I only originally posted to see if anybody had any ideas. After a few days of hearing nothing, I switched to another menu system. I certainly do not expect people to spend time debugging my own problems like some kind of customer service department. A forum post is just a discussion area and that's why I posted. To discuss the issue.

You have told me to spare you my judgment. I'd like to ask the same of you.

In regard to what you said about the troubleshooting section, sometimes the solutions to problems aren't easily inferable at the start from the symptoms. So yes, sometimes they are unusual fixes to problems that nobody would expect. For that reason, I did try it. However, even looking over the list again, I can see why I thought it was unlikely in the extreme to solve anything. Either way, it doesn't matter now because it didn't make any difference.

I didn't say it will solve the problem. It's just that posting information
like that ("went through the troubleshoot section, but nothing helped")
is a thousands more helpful than browsing the cvs log and extracting
entries that contain some word.

The posting from leileilol along with the description in your last but one's
should get to the problem rather easily.

Hitting escape once seems to stop the scrolling, a second press seems unnecessary at this end. However, it can be simply be started again by pressing a key (which then automatically repeats).

Interestingly, pressing enter in the menu does not stop the problem from occurring again. It seems only pressing enter on the command-line is effective. Pressing enter in the menu once in fact made it lock-on, repeating over and over. This is also what happens to the arrow keys, although the numbers and letters appear unaffected.

I compiled the new CVS code a few days ago when I was thinking about changing DOS menu programs permanently and found this issue seems to of been solved. So thanks to whoever implemented it 😀