Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
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,
toggle quoted message
Show quoted text
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'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 installerthe logical next step from the last set of changes, which were stillThis seems somewhat simpler.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 thetree) of these within the next week.to the point where I won't be embarrassed handing it out to people. |
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 inThat'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,
toggle quoted message
Show quoted text
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,can recall that ever created user folders in the Windows folder! Based onthat perhaps something is amiss in the interpretation of the Windows standardsthe drive that Windows is installed on (usually C ) or (b) in the My DocumentsI 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 |
to navigate to use esc to dismiss