开云体育

Locked A new test upload


 

I've uploaded a new test 0.9.3.5 version of the Windows installer version. I hope that this is starting to converge ...

This is meant to test a new GUI for selecting the decoder model. This one displays the decoders in a tree form. This seems to be the logical next step from the last set of changes, which were still somewhat confusing with Soundtraxx's complicated product line. This seems somewhat simpler.

I would _very_ much like feedback on whether this is an improvement. I'd like to settle on one of the three (original selection boxes, the one with manufacturer and decoder lists, and this one with the tree) of these within the next week.

Also new, hence needing testing:

Digitrax FX3 decoders

Additional older Lenz & Digitrax decoders

Create decoder index automatically in case of mismatch

New LocoTools application, which gathers in one place the
various LocoNet tools in the JMRI libraries

JMRI demo is now installed by default

Users with an Empire Builder will have their "read" buttons
disabled & labeled so its clear why they don't work.

Two minor bugs in the Lenz LI100 fixed; now works well
with the Atlas Commander

The file is available in the usual place on SourceForge:



This is just about the end of my high-priority list of changes. Nowhere near the end of the entire list, of course, but at least to the point where I won't be embarrassed handing it out to people.

So, after fixing the inevitable bugs, the next step is to pull together some documentation and create a master CD. Help would be greatly appreciated.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Am working off a huge email backlog, call if it's urgent.


Jon Miller
 

I just installed V0.9.3.5 and everything seemed to go fine. I didn't do
any programming or other testing but everything opened as it should. I will
reserve comment about the current version until I have time to do testing
and programming but initial feeling are that it looks great. My machine is
a 233 Intel running Win98 Ver2.
It did do an interesting thing and came up with a password input if
desired. Probably part of the installer. It's not a problem and I made it
go away<G>.

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS


Al Silverstein
 

Bob,

I just tried the update and it appears to be working OK in general. I did have one small problem. It did not recognize my decoder. The decoder is a DN146A and is installed in a Atlas U25B.

The software recognized the decoder as belonging to Digitrax but could not determine the type. It reported the version as 106.

Where is the problem?

Al

----- Original Message -----
From: Bob Jacobsen
To: jmriusers@...
Sent: Friday, July 05, 2002 4:19 AM
Subject: [jmriusers] A new test upload


I've uploaded a new test 0.9.3.5 version of the Windows installer
version. I hope that this is starting to converge ...

This is meant to test a new GUI for selecting the decoder model.
This one displays the decoders in a tree form. This seems to be the
logical next step from the last set of changes, which were still
somewhat confusing with Soundtraxx's complicated product line. This
seems somewhat simpler.

I would _very_ much like feedback on whether this is an improvement.
I'd like to settle on one of the three (original selection boxes, the
one with manufacturer and decoder lists, and this one with the tree)
of these within the next week.

Also new, hence needing testing:

Digitrax FX3 decoders

Additional older Lenz & Digitrax decoders

Create decoder index automatically in case of mismatch

New LocoTools application, which gathers in one place the
various LocoNet tools in the JMRI libraries

JMRI demo is now installed by default

Users with an Empire Builder will have their "read" buttons
disabled & labeled so its clear why they don't work.

Two minor bugs in the Lenz LI100 fixed; now works well
with the Atlas Commander

The file is available in the usual place on SourceForge:



This is just about the end of my high-priority list of changes.
Nowhere near the end of the entire list, of course, but at least to
the point where I won't be embarrassed handing it out to people.

So, after fixing the inevitable bugs, the next step is to pull
together some documentation and create a master CD. Help would be
greatly appreciated.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Am working off a huge email backlog, call if it's urgent.

To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


 

At 5:59 PM -0400 7/5/02, Al Silverstein wrote:
Bob,

I just tried the update and it appears to be working OK in general. I did have one small problem. It did not recognize my decoder. The decoder is a DN146A and is installed in a Atlas U25B.
The software recognized the decoder as belonging to Digitrax but could not determine the type. It reported the version as 106.
Where is the problem?
I've never seen a DN146A that has a version (CV7 value) of 106. The definition file is coded to look for DN146A (and other members of that family) as versions 33 through 45 inclusive, which is why it didn't find yours.

I can add the 106 value to the search list for the DN146A.

Do you have other DN146A decoders? If so, what are their CV7 values? (They easiest way to look is probably with the single CV programmer from the menu bar)

In the larger picture, the problem lies with the NMRA specifications. They're not specific enough in what CV7 means, so some manufacturers don't provide enough information in that CV to make exact identification possible. A couple of people are working on doing something about that, but it will take a while.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Am working off a huge email backlog, call if it's urgent.


rjs4005
 

Bob:

I've been quietly following your group as well as downloading and
testing the software. I currently have the following:
Computer: Dell Latitude C800 laptop, Win XP Pro, 256 RAM.
DCC: Digitrax Chief (DCS100).

I downloaded and tested the software last night. It worked with no
problems. I programmed a Digitrax DN163K decoder with some minor
hiccups. (Light settings) Need to play some more on that.

I would like to see if there is a way to detect and add new decoders
in to the listing you've created.

Other than that, I like the program.

Keep up the good work.

Bob Stanek


--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:
I've uploaded a new test 0.9.3.5 version of the Windows installer
version. I hope that this is starting to converge ...

This is meant to test a new GUI for selecting the decoder model.
This one displays the decoders in a tree form. This seems to be
the
logical next step from the last set of changes, which were still
somewhat confusing with Soundtraxx's complicated product line.
This
seems somewhat simpler.

I would _very_ much like feedback on whether this is an
improvement.
I'd like to settle on one of the three (original selection boxes,
the
one with manufacturer and decoder lists, and this one with the
tree)
of these within the next week.

Also new, hence needing testing:

Digitrax FX3 decoders

Additional older Lenz & Digitrax decoders

Create decoder index automatically in case of mismatch

New LocoTools application, which gathers in one place the
various LocoNet tools in the JMRI libraries

JMRI demo is now installed by default

Users with an Empire Builder will have their "read" buttons
disabled & labeled so its clear why they don't work.

Two minor bugs in the Lenz LI100 fixed; now works well
with the Atlas Commander

The file is available in the usual place on SourceForge:



This is just about the end of my high-priority list of changes.
Nowhere near the end of the entire list, of course, but at least
to
the point where I won't be embarrassed handing it out to people.

So, after fixing the inevitable bugs, the next step is to pull
together some documentation and create a master CD. Help would be
greatly appreciated.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)
Am working off a huge email backlog, call if it's urgent.


Robin Becker
 

Bob,

It looks like the installer put JMRI/programmers and JMRI/roster folders in
the Windows folder on my machine. This seems unusual to me. I checked and
the roster info is being stored there. I think that normally programs would
not put anything in the Windows folder except maybe system .exe or .dll
files, and possibly an .ini file. The user roster info should be stored
with the other program info (ProgramFiles/jmri).

Robin


 

It looks like the installer put JMRI/programmers and JMRI/roster folders in
the Windows folder on my machine. This seems unusual to me. I checked and
the roster info is being stored there. I think that normally programs would
not put anything in the Windows folder except maybe system .exe or .dll
files, and possibly an .ini file. The user roster info should be stored
with the other program info (ProgramFiles/jmri).
That's what I thought too, which is why the program originally kept them together. But when I went to a "real" installer, I discovered that there are Windows "recommendations" that it enforces, and one of them is that the program should not modify the contents of the program's folder. Instead, programs are supposed to put their "preferences" and similar things in a separate place. For some versions of Windows (the ones with years, e.g. Win95) that's the Windows folder. For others (XP, and perhaps others) there's a user-specific folder that's required.

I'm not sure why it insists on this. It might be due to the way Windows keeps tracks of "officially installed" components so that it can uninstall them.

Its possible, though not easy, to get around it. The tricky bit would be to make sure that the old preferences don't get removed when a new version is inserted by the installer.

Is this something I should change?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)


Robin Becker
 

Bob,

Interesting. In many years of using Windows this is the first program I can
recall that ever created user folders in the Windows folder! Based on that
perhaps something is amiss in the interpretation of the Windows standards
that they followed, I don't know. In any case, IMHO the Windows folder is
an especially bad place to put data files for a number of reasons. My
suggestion is that the jmri folder be created either (a) on the root of the
drive that Windows is installed on (usually C ) or (b) in the My Documents
folder on that drive.

Robin

-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Tuesday, July 09, 2002 11:55 AM
To: jmriusers@...
Subject: RE: [jmriusers] A new test upload


>It looks like the installer put JMRI/programmers and JMRI/roster folders
in
>the Windows folder on my machine. This seems unusual to me. I checked
and
>the roster info is being stored there. I think that normally programs
would
>not put anything in the Windows folder except maybe system .exe or .dll
>files, and possibly an .ini file. The user roster info should be stored
>with the other program info (ProgramFiles/jmri).

That's what I thought too, which is why the program originally kept
them together. But when I went to a "real" installer, I discovered
that there are Windows "recommendations" that it enforces, and one of
them is that the program should not modify the contents of the
program's folder. Instead, programs are supposed to put their
"preferences" and similar things in a separate place. For some
versions of Windows (the ones with years, e.g. Win95) that's the
Windows folder. For others (XP, and perhaps others) there's a
user-specific folder that's required.

I'm not sure why it insists on this. It might be due to the way
Windows keeps tracks of "officially installed" components so that it
can uninstall them.

Its possible, though not easy, to get around it. The tricky bit
would be to make sure that the old preferences don't get removed when
a new version is inserted by the installer.

Is this something I should change?

Bob


Alex Shepherd
 

Bob,

Interesting. In many years of using Windows this is the first program I
can
recall that ever created user folders in the Windows folder! Based on
that
perhaps something is amiss in the interpretation of the Windows standards
that they followed, I don't know. In any case, IMHO the Windows folder is
an especially bad place to put data files for a number of reasons. My
suggestion is that the jmri folder be created either (a) on the root of
the
drive that Windows is installed on (usually C ) or (b) in the My Documents
folder on that drive.

Robin
I think what the installer is trying to do is split out the shared
executable and data components from the user preferences/settings so that
multiple users on the same PC can have their own preferences/settings and
not interfer with each other.

However on the older Windows systems that either do not handle or do not
have individual users defined, the fall back is to place those files in the
/Windows directory or wherever it decides is best.

If you have defined any users on the system you may well find that it does
something different and places the prefs under some obscure user home
directory somewhere else...

I think the current behaviour is working as I would expect for systems like
NT/Win2K/XP and Linux that have the fundamental notion of individual users.
The older and non protected Windows systems try and fake the notion of
individual users so they can have separate preferences but it is really only
a very thin vineer...

I think someone needs to experiement with the systems that don't have a
strong notion of a user's home directory, to find out what needs to be
defined to coax it to place the files where you would expect...

Failing that, a work-around maybe to add logic to the batch file to detect
if there is a home directory defined as an environment variable and if not
define one so that what Java uses as its "user.home" is what you expect.

Cheers

Alex