Loading ...
Sorry, an error occurred while loading the content.

Re: [aprsisce] Multiple Settings Profiles

Expand Messages
  • Gary Sanders
    In following the ongoing discussion of Profiles vs Separate instances something kept gnawing at me, and I think some old group discussions finally came back
    Message 1 of 34 , Jan 29, 2013
    • 0 Attachment
      In following the ongoing discussion of Profiles vs Separate instances
      something kept gnawing at me, and I think some old group discussions
      finally came back into my consciousness.

      Lynn, didn't you say a couple of years ago that the XML file
      structure/content could be subject to change at any time as the program
      matures?

      Is the implication of that (IF my recollection is correct) that a change
      to the XML file (due to modification of the base program) could
      conceivably force a user with a bunch of separate instances of APRSISCE
      set up in separate directories to either (1) start from scratch,
      importing the new version of the XML into each instance, and then
      setting each one up, or (2) edit EACH separate XML file to accommodate
      the changes? Obviously, such a case would depend entirely on how
      substantial the XML file changes were.

      It would seem (from a non-programmer's understanding of How Things Work)
      that it would be easier to make internal changes to a built-in Profile
      subsystem to accommodate XML file changes, rather than hope that the end
      user recognizes the need to update the XML file as needed.

      The Profile subsystem could even highlight changes to the program that
      might require a change to the users Profiles, and notify the user as
      appropriate.

      Gary Sanders

      W0BY

      On 1/29/2013 5:48 PM, Lynn W Deffenbaugh (Mr) wrote:
      >
      >
      > No, you only need a single copy of the .EXE, but you'll need to make a
      > shortcut of that .EXE to run within the different directory that
      > contains the .XML and will end up with the .LOGs. I have a single
      > APRSIS32.EXE in D:\DEBUG with probably 30+ subdirectories each with just
      > the APRSIS32.XML for various test configurations. I run the .EXE from
      > the parent directory but have the default directory be the sub.
      >
      > BUT, you can still put a .EXE into each directory. I do that when I
      > want to freeze my production IGate at a current version and only do an
      > upgrade when I'm confident that things are stable enough. With a shared
      > and short-cut-ed .EXE, you upgrade one image and then just close and
      > restart the others. With dedicated .EXEs, each of the instances will
      > need to download the update.
      >
      > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
      >
      > On 1/29/2013 5:25 PM, Adam Mahnke wrote:
      >> AH HA, so if I want to be running one instance on the ISS freqency, or
      >> HF, then I will need a seperate exe file from the 2M IGate with it's
      >> own xml file.
      >>
      >> Adam
      >>
      >> ------------------------------------------------------------------------
      >> To: aprsisce@yahoogroups.com
      >> From: kb8rco@...
      >> Date: Tue, 29 Jan 2013 14:18:57 -0800
      >> Subject: Re: [aprsisce] Multiple Settings Profiles
      >>
      >> That may be so, but Adam is correct that there doesn't seem to be
      >> anything in the WIKI about running "mutiple setups" or "multiple
      >> instances".
      >> "Multiple Setups" is just having more thanone XML file with differences.
      >> "Multiple Instances" does required multiple setups, with more than one
      >> running on the same machine at the same time.
      >> Robert Giuliano
      >> KB8RCO
      >>
      >>
      >> ---------------------------------------------
      >> *From:* James Ewen <ve6srv@...>
      >> *To:* aprsisce@yahoogroups.com
      >> *Sent:* Tuesday, January 29, 2013 5:00 PM
      >> *Subject:* Re: [aprsisce] Multiple Settings Profiles
      >> Adam,
      >>
      >> You're the only one not on the wagon here!
      >>
      >> On 1/29/13, Adam Mahnke mailto:kc2ant%40hotmail.com> wrote:
      >> >
      >> > for the group.
      >> >
      >> > This is a much better idea.
      >> >
      >> > Maybe it's an idea for "advanced wiki fodder"
      >> >
      >> > It's the same concept as I described for using multiple folders, but only
      >> > one exe to update.
      >> >
      >> > I'll be changing my set ups.
      >> >
      >> > Adam
      >> > KC2ANT
      >> >
      >> >
      >> >
      >> >
      >> > To: mailto:aprsisce%40yahoogroups.com
      >> > From: mailto:kb8rco%40yahoo.com
      >> > Date: Tue, 29 Jan 2013 07:57:57 -0800
      >> > Subject: Re: [aprsisce] Multiple Settings Profiles
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> >
      >> > You don't need multiple EXE files. You can have each shortcut call
      >> the same
      >> > (common) EXE file, but from a different "Start In" directory. his makes
      >> > updates easy.
      >> >
      >> > If you are physically running multiple instances, then only the instance
      >> > that updates will actually restart into the new version. All other
      >> running
      >> > instances must be manually restarted for the update to take affect.
      >> >
      >> >
      >> > Robert Giuliano
      >> > KB8RCO
      >> >
      >> >
      >> >
      >> > ---------------------------------------------
      >> >
      >> >
      >> >
      >> >
      >> > From: Adam Mahnke mailto:kc2ant%40hotmail.com>
      >> > To: "mailto:aprsisce%40yahoogroups.com"
      >> mailto:aprsisce%40yahoogroups.com>
      >> > Sent: Monday, January 28, 2013 11:55 AM
      >> > Subject: RE: [aprsisce] Multiple Settings Profiles
      >> >
      >> >
      >> >
      >> >
      >> > I think you've pretty much got it Lynn. The only serious advantage I
      >> see to
      >> > having it done inside the program is that when you release an update
      >> it only
      >> > has to be done once, instead of however many instances someone may
      >> have. Big
      >> > deal, it doesn't take that long. IMHO of course.
      >> >
      >> >
      >> > Right now I have multiple shortcuts on my desktop with names indicating
      >> > which configuration APRSIS32 is being used for. I decide which one I
      >> want,
      >> > double click on it and I"m off to the races. if I want to change to
      >> another
      >> > one, I close it, double click the new one, and away I go. They all
      >> share the
      >> > same NWS shape file directory, they all share the same map tiles. The
      >> only
      >> > thing in the respective directories is the EXE, XML and associated log
      >> > files.
      >> >
      >> >
      >> > I don't think you really need to have something in program to match the
      >> > Kenwoods PM capability, it's already there through windows functionality,
      >> > just takes more than a couple of button presses, but not MUCH more.
      >> >
      >> >
      >> > My PM's are set up as such.
      >> > PMoff, VFO, no TNC
      >> > PM1 the YL's call sign, D710 native APRS mode only
      >> > PM2 MY Callsign, Native APRS and this is the one that I use for
      >> connecting
      >> > APRSIS32 to. Regardless of the mode of operation I'm using with APRSIS32.
      >> > PM3 My callsign, Packet mode.
      >> > PM4 SKYCommand Operations with TS-2000s
      >> > PM5 Public service frequencies for use when my fire duties require them.
      >> >
      >> >
      >> > the only settings that save across each and every one of those, are
      >> changes
      >> > that I make to the stored memory channels. nothing to do with APRS
      >> settings
      >> > transfers from one to the other.
      >> >
      >> >
      >> > FWIW, my D700 in my plow truck has similar settings in the PM saves.
      >> >
      >> >
      >> > I really think that mimicking the PM option from kenwood within
      >> APRSIS32 is
      >> > moot, educating folks on how to use the directory set up within
      >> windows is
      >> > the solution. Save map files in one place, all instances of APRSIS32
      >> use the
      >> > same tiles. Copy the EXE and XML to a new directory, make your
      >> changes and
      >> > save. BINGO, new "PM" settings. Rinse, wash repeat for as many
      >> different set
      >> > ups as one wants.
      >> >
      >> >
      >> > like I said, the only draw back to that is when Lynn releases an update
      >> > every day for a week (or more often) then each one needs to be
      >> updated, but
      >> > for me, that's really not that big a deal, and honestly, even if I
      >> don't run
      >> > the update, the program still works just fine as it has been sense
      >> the last
      >> > set of updates.
      >> >
      >> >
      >> > Just my $.04 (I typed too much for 2)
      >> >
      >> >
      >> > Adam
      >> > KC2ANT
      >> >
      >> >
      >> > To: mailto:aprsisce%40yahoogroups.comFrom:
      >> mailto:kj4erj%40arrl.netDate: Mon, 28 Jan 2013
      >> > 10:15:15 -0500Subject: Re: [aprsisce] Multiple Settings Profiles
      >> >
      >> >
      >> >
      >> > On 1/28/2013 10:11 AM, Rob Giuliano wrote:
      >> >
      >> > The down side is that a single change that you want across ALL XML
      >> has to be
      >> > repeated for each setup (each directory), but you won't change things on
      >> > other setups (directory). The same is true with Kenwood's PMs, isn't it?
      >> > If you've got a change you want to make to all PMs, you need to
      >> recall it,
      >> > make the change, and save it away. So I'm still struggling to see
      >> what the
      >> > difference is between a set of XMLs in unique directories and a Kenwood
      >> > PM?With proper shortcuts in a single place, it's just about as easy
      >> to close
      >> > an instance and open a different one as it is to figure out which PM
      >> number
      >> > has the settings you're looking for this time...Am I still missing
      >> > something? Or what is the actual use case for easily switching (some)
      >> > configuration parameters for different modes of operation that requires
      >> > explicit multi-configuration support in APRSISCE/32?Lynn (D) - KJ4ERJ -
      >> > Author of APRSISCE for Windows Mobile and Win32
      >> >
      >> >
      >> >
      >> >
      >> >
      >>
      >> --
      >> Sent from my mobile device
      >>
      >> James
      >> VE6SRV
    • Lynn W Deffenbaugh (Mr)
      ... Yep, that would do it as the general release is nearly always lagging being the development version. I just wanted to make sure that the reversion
      Message 34 of 34 , Jan 30, 2013
      • 0 Attachment
        On 1/30/2013 6:59 AM, Colin XSD wrote:
        > On 30/01/2013 02:15, Lynn W Deffenbaugh (Mr) wrote:
        >> Has anyone ever gotten the startup warning that the configuration was
        >> saved by a later version of APRSISCE/32 and warned that it might not be
        >> reliable to go backwards in versions?
        > Yes Lynn, many times, I just ignored it:S. It has never caused me any
        > concern.
        >
        > I think I normally see that warning when I cut & paste bits into a new
        > xml file but forget to change the 'Dev' flag.

        Yep, that would do it as the general release is nearly always lagging
        being the development version. I just wanted to make sure that the
        reversion detection code was actually working in light of the recent
        discussion of multiple configurations and XML files and preserved
        settings. I attempt to do backward compatibility by
        migrating/converting/upgraded XML settings in the new versions. But
        sometimes that conversion is one-way and if you take an upgraded XML and
        load it into a back-level version, those settings may revert to default
        values. Hence the warning. Nothing particularly "bad" will happen, but
        your settings may not be as you expect.

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
      Your message has been successfully submitted and would be delivered to recipients shortly.