*moved from public.xbase++.generic*

Till Warweg wrote:

> integrated into your personal environment. So it seems to me that in this
> discussion, we're basically talking about just  the "copying files" part
> of the installation. Correct?

Yes - basically just give me a ZIP file with all the files and I'm happy
and shall not bother you again 

I don't use neither the workbench nor CXP or the workbench, so I don't need
all the complicated details that might be built into the installer like IIS
integration (even don't use IIS).

I tried to use the msiexec /a switch with your installer to put all the
files into a single location but it does not behave like other msi
installers I have used in the past - not sure where all the files ended up
though.

If using the installer, I would also like to deselect the Worksbench -
which currently is not possible.

And from the "simple user" perspective, putting the selections for CXP,
environment change and WAA into the "Custom setup" dialog is also not
optimal:

Because the installer UI is confined to a fixed-size dialog window, there
are two ugly  scrollbars that make it a pain to select or deslect options
because you have to scroll around to actually read what every option
exactly does.

The dialog does not show where all the components are actually installed.

I think it would be better to have separate pages with some explanatory
text what the "special" options like CXP, WAA actually are for.

Especially the important switch for changing the environment gets "lost"
between all the other options and should have its own page with a checkbox
to select.
 
> Your sentiments seem to be different, however, so let's go back to them.
> I'd like to ask you to put personal feelings  aside (and yeah, I was
> pi..ed by some of the allegations in this thread!) and talk to us -
> again!

HA! Actually never stopped talking to you 

> The  question that I'm still struggling with is this: supposed the
> installer gave you that "Choose location" button, and  you'd be able to
> move the whole folder hierarchy to <my place on drive>, where would you
> go from there?

I would copy all of those files underneath d:\Alaska\XPP<build number> and
create a new batch to switch the environment:

@ECHO OFF
CLS

IF EXIST N:\ SUBST N: /D
SUBST N: D:\ALASKA\XPP2014

:END

But this assumes the following sub-directory structure:

bin
book
Gateway
include
lib
resource
runtime
Server
waa1w32
WAABase

Of course this does not work if the Alaska files are in seperate base
directories or even separate drives...

> What about the  environment, file associations etc.? 

This is already set up, no need to fiddle with that:

INCLUDE=N:\include
LIB=N:\LIB;N:\runtime
Path=N:\Runtime;N:\BIN;N:\LIB;N:\include;

And i don't need any file associations because I do not work from the
explorer environment but directly from within MultiEdit:

I press F9, <ENTER><ENTER> to compile
I press F9, <ENTER>,CP <ENTER> to copy the new exe and DLL files over to
the WAA directory
I also commit file changes to my Subversion repository from within
MultiEdit.

Thomas

Thomas Braun wrote in news:12i3mjqr6z4ij$.1iy2vseo3k3rf.dlg@40tude.net:

Till,

What thomas said works for me also..

> *moved from public.xbase++.generic*
> 
> Till Warweg wrote:
> 
>> integrated into your personal environment. So it seems to me that in
>> this discussion, we're basically talking about just  the "copying
>> files" part of the installation. Correct?
> 
> Yes - basically just give me a ZIP file with all the files and I'm
> happy and shall not bother you again 
> 
> I don't use neither the workbench nor CXP or the workbench, so I don't
> need all the complicated details that might be built into the
> installer like IIS integration (even don't use IIS).
> 
> I tried to use the msiexec /a switch with your installer to put all
> the files into a single location but it does not behave like other msi
> installers I have used in the past - not sure where all the files
> ended up though.
> 
> If using the installer, I would also like to deselect the Worksbench -
> which currently is not possible.
> 
> And from the "simple user" perspective, putting the selections for
> CXP, environment change and WAA into the "Custom setup" dialog is also
> not optimal:
> 
> Because the installer UI is confined to a fixed-size dialog window,
> there are two ugly  scrollbars that make it a pain to select or
> deslect options because you have to scroll around to actually read
> what every option exactly does.
> 
> The dialog does not show where all the components are actually
> installed. 
> 
> I think it would be better to have separate pages with some
> explanatory text what the "special" options like CXP, WAA actually are
> for. 
> 
> Especially the important switch for changing the environment gets
> "lost" between all the other options and should have its own page with
> a checkbox to select.
>  
>> Your sentiments seem to be different, however, so let's go back to
>> them. I'd like to ask you to put personal feelings  aside (and yeah,
>> I was pi..ed by some of the allegations in this thread!) and talk to
>> us - again!
> 
> HA! Actually never stopped talking to you 
> 
>> The  question that I'm still struggling with is this: supposed the
>> installer gave you that "Choose location" button, and  you'd be able
>> to move the whole folder hierarchy to <my place on drive>, where
>> would you go from there?
> 
> I would copy all of those files underneath d:\Alaska\XPP<build number>
> and create a new batch to switch the environment:
> 
> @ECHO OFF
> CLS
> 
> IF EXIST N:\ SUBST N: /D
> SUBST N: D:\ALASKA\XPP2014
> 
>:END
> 
> But this assumes the following sub-directory structure:
> 
> bin
> book
> Gateway
> include
> lib
> resource
> runtime
> Server
> waa1w32
> WAABase
> 
> Of course this does not work if the Alaska files are in seperate base
> directories or even separate drives...
> 
>> What about the  environment, file associations etc.? 
> 
> This is already set up, no need to fiddle with that:
> 
> INCLUDE=N:\include
> LIB=N:\LIB;N:\runtime
> Path=N:\Runtime;N:\BIN;N:\LIB;N:\include;
> 
> And i don't need any file associations because I do not work from the
> explorer environment but directly from within MultiEdit:
> 
> I press F9, <ENTER><ENTER> to compile
> I press F9, <ENTER>,CP <ENTER> to copy the new exe and DLL files over
> to the WAA directory
> I also commit file changes to my Subversion repository from within
> MultiEdit.
> 
> Thomas
>

Brian Wolfsohn wrote in news:XnsA3BE5BE55CDCCblwcuscom@87.106.143.233:

> What thomas said works for me also..

same hre

Best regards,
Boris Borzic

http://xb2.net
http://sqlexpress.net
industrial strength Xbase++ development tools

Thomas Braun wrote:

> I tried to use the msiexec /a switch with your installer to put all the
> files into a single location but it does not behave like other msi
> installers I have used in the past - not sure where all the files ended up
> though.

By chance I now found the files... they have been copied into the F:\ drive
on my workstation, which happens to be the main network share here...
weird.

The installer created the following directories directly underneath F:\

Redist
Win
DIR289
DIR19
DIR23

Plus xpp-prof.20-00-554.en.msi in the root of the drive.

If I use the /a switch with the Acrobat reader, it asks me where to put
the files - but probably that's something the designers of the installer
have set up that way.

So, from what I can see, the only things currently relevant to me are 

\DIR23\Alaska Software\xpp20 (contains the core product)
\DIR23\Alaska Software\waa20 (contains WAA)
\DIR19\Xbase++ (contains runtime and sample source code plus WAA samples)

Thomas

Hi Thomas,

I have mentioned this in another post, here again for completeness.

The installation package currently does not support the admin mode.
We will correct that in a future update.

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:oo9k05ezdlgn.m2rm1esw0737.dlg@40tude.net...
> Thomas Braun wrote:
>
>> I tried to use the msiexec /a switch with your installer to put all the
>> files into a single location but it does not behave like other msi
>> installers I have used in the past - not sure where all the files ended 
>> up
>> though.
>
> By chance I now found the files... they have been copied into the F:\ 
> drive
> on my workstation, which happens to be the main network share here...
> weird.
>
> The installer created the following directories directly underneath F:\
>
> Redist
> Win
> DIR289
> DIR19
> DIR23
>
> Plus xpp-prof.20-00-554.en.msi in the root of the drive.
>
> If I use the /a switch with the Acrobat reader, it asks me *where* to put
> the files - but probably that's something the designers of the installer
> have set up that way.
>
> So, from what I can see, the only things currently relevant to me are
>
> \DIR23\Alaska Software\xpp20 (contains the core product)
> \DIR23\Alaska Software\waa20 (contains WAA)
> \DIR19\Xbase++ (contains runtime and sample source code plus WAA samples)
>
> Thomas

Andreas Herdt wrote:

> I have mentioned this in another post, here again for completeness.

Ok - did not see this - thanks for mentioning again.

Thomas

Thomas Braun wrote:

> But this assumes the following sub-directory structure:
> 
> bin
> book
> Gateway
> include
> lib
> resource
> runtime
> Server
> waa1w32
> WAABase

Actually, this one is quite essential!

Since the "book" directory is gone (it is called "help20" now), I can't use
the automatic online help in my editor anymore unless I copy the content of
help 20 to the old (correct) location.

Probably I will have to create a copy script to copy the files over to the
correct location.

I have also found that the WAA gateway source is no longer available.

Thomas

Hi Thomas,

Can you please tell us what the technical reasons are. Why can't you use
the online help with the "automatic help" in your editor.

Give us some background.

With my best regards,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:mfaolral9k25$.r8ygcwq7a2pz.dlg@40tude.net...
> Thomas Braun wrote:
>
>> But this assumes the following sub-directory structure:
>>
>> bin
>> book
>> Gateway
>> include
>> lib
>> resource
>> runtime
>> Server
>> waa1w32
>> WAABase
>
> Actually, this one is quite essential!
>
> Since the "book" directory is gone (it is called "help20" now), I can't 
> use
> the automatic online help in my editor anymore unless I copy the content 
> of
> help 20 to the old (correct) location.
>
> Probably I will have to create a copy script to copy the files over to the
> correct location.
>
> I have also found that the WAA gateway source is no longer available.
>
> Thomas

Andreas Herdt wrote:

> Can you please tell us what the technical reasons are. Why can't you use
> the online help with the "automatic help" in your editor.

Sorry - never mind, I just managed to get that set up properly.

The only downside to it is that I now have multiple help entries, one for
v2.0 and one for the older versions, but that is no big deal.

Thomas

Hi Thomas,

Sorry for persisting on this 

What is the reason for the two help menu entries? How does the help dialog 
of your editor work. Maybe we can find an easy way to come around this 
shortcoming.

When working with different versions concurrently then thinking about what 
item to select could hamper you working in an efficient way?

With my best regards,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:1pcvppzvlb326.1drdynpfsxr6v$.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> Can you please tell us what the technical reasons are. Why can't you use
>> the online help with the "automatic help" in your editor.
>
> Sorry - never mind, I just managed to get that set up properly.
>
> The only downside to it is that I now have multiple help entries, one for
> v2.0 and one for the older versions, but that is no big deal.
>
> Thomas

Andreas Herdt wrote:

> Sorry for persisting on this 



> What is the reason for the two help menu entries? How does the help dialog 
> of your editor work.

In Multiedit you can press Ctrl-F1 to get context sensitive help.

There is a global help setup which defines what help files exist, so you
have a global list of n help files (with the actual path and file name)

From that global list you can define a subset that is only valid for a
specific editor file extension (.prg / . html/ etc...) so when you press
Ctrl-F1 while editing a prg file you are able to get a different help
selection than if you are editing a html file.

With the old directory structure I had a single entry:

N:\book\xppref.hlp

When switching the Xbase++ version I only substituted one \book\ directory
with the other.

But now, because the help file names changed as well I need one for
\book\xppref.hlp and one for \whatever path\xpplang20.chm

> Maybe we can find an easy way to come around this 
> shortcoming.

I don't think so.

> When working with different versions concurrently then thinking about what 
> item to select could hamper you working in an efficient way?

No, that is no real problem for me - but you can see what consequences the
rearranged directory structures can have.

Thomas

Hi Thomas,

> From that global list you can define a subset that is only valid for a
> specific editor file extension (.prg / . html/ etc...) so when you press
> Ctrl-F1 while editing a prg file you are able to get a different help
> selection than if you are editing a html file.

> But now, because the help file names changed as well I need one for
> \book\xppref.hlp and one for \whatever path\xpplang20.chm

So the problem is not the path to the help, it is the naming of the
help file and it's format.

>> Maybe we can find an easy way to come around this
>> shortcoming.
>
> I don't think so.

Me so either.

Weird things would be required to do. You need to modify the editors
global list on the fly.....

Thank you for describing the details. This helps to understand.

With my best regards,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:1s5xxqj24gmkp$.fg8bh4c3rsbf$.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> Sorry for persisting on this ;-)
>
> :-)
>
>> What is the reason for the two help menu entries? How does the help 
>> dialog
>> of your editor work.
>
> In Multiedit you can press Ctrl-F1 to get context sensitive help.
>
> There is a global help setup which defines what help files exist, so you
> have a global list of n help files (with the actual path and file name)
>
> From that global list you can define a subset that is only valid for a
> specific editor file extension (.prg / . html/ etc...) so when you press
> Ctrl-F1 while editing a prg file you are able to get a different help
> selection than if you are editing a html file.
>
> With the old directory structure I had a single entry:
>
> N:\book\xppref.hlp
>
> When switching the Xbase++ version I only substituted one \book\ directory
> with the other.
>
> But now, because the help file names changed as well I need one for
> \book\xppref.hlp and one for \whatever path\xpplang20.chm
>
>> Maybe we can find an easy way to come around this
>> shortcoming.
>
> I don't think so.
>
>> When working with different versions concurrently then thinking about 
>> what
>> item to select could hamper you working in an efficient way?
>
> No, that is no real problem for me - but you can see what consequences the
> rearranged directory structures can have.
>
> Thomas

Hi Thomas,

Let me just give some brief answers to some of your remarks:

> I tried to use the msiexec /a switch with your installer to put all the
> files into a single location but it does not behave like other msi
> installers I have used in the past - not sure where all the files ended up
> though.

The ADMIN mode is not supported by the Xbase++ installer. To me
this seems to be an oversight and should be corrected with a future
update.

> And from the "simple user" perspective, putting the selections for CXP,
> environment change and WAA into the "Custom setup" dialog is also not
> optimal:
>
> Because the installer UI is confined to a fixed-size dialog window, there
> are two ugly scrollbars that make it a pain to select or deslect options
> because you have to scroll around to actually read what every option
> exactly does.

Or it is a matter of the installer's UI that just seems not to be large 
enough
to hold all items without the need of scrollbars. We liked the idea of
one central place to switch features ON or OFF for installation. This also
lets you configure/change the installation from the control panels Program
Settings dialog where you find the option "Change". Disabling the
Environment feature just removes the environment that might have been
selected by accident, for example. No other feature is affected in this
case.

> The dialog does not show where all the components are actually 
> installed.

The idea is that everything is installed at distinct folders. I agree that
the installer does not tell you that the sources go to Documents\Xbase++\..,
the CXP samples go to wwwroot\websamples (in case an IIS is available)
and that all binaries go to Programfiles\Alaska Software.

> I think it would be better to have separate pages with some explanatory
> text what the "special" options like CXP, WAA actually are for.

Don't know what you mean saying "special". These are just optonal features
you can omit on installation. Clicking each individual feature displays a
descriptive text what the feature is good for. Here again: There is not much
place to show long text, you have a point here.

I think that the following is your "main" point:

> But this assumes the following sub-directory structure:
>
> bin
> book
> Gateway
> include
> lib
> resource
> runtime
> Server

Am I right that the most pressing issue here is that you can no longer
switch your environment with respect of the Xbase++ version used
in the same way you have done before?

To say this first: We as the vendor should be allowed to change the
details of the folder structure and naming. What was previously named

XPPW32\bin
XPPW32\lib
....

now is named

xpp20\bin
xpp20\lib
...

We also decided to move the online help, the server and other things
away as these are items that do not necessarily are sticked to a distinct
version of the development tools

cxp20\bin
waa20\server
...

Insofar not much has been changed in this area.

In case the installer installs the product to an optional folder then
I would assume this option will be set for the entire product. In
your case this will mean you will have the following on your drive
by selecting d:\alaska\xpp2014 as destination folder:

D:\ALASKA\XPP2014\xpp20
D:\ALASKA\XPP2014\help
D:\ALASKA\XPP2014\waa20

Your batch file for using that version of Xbase++ would then look
like this:

============ snip ==============
 @ECHO OFF
 CLS

 IF EXIST N:\ SUBST N: /D
 SUBST N: D:\ALASKA\XPP2014\xpp20

 :END

============ snap ==============

Think about the following 

============ snip ==============
  SUBST N: "C:\Program Files\Alaska Software\xpp20"
============ snap ==============

Please consider our main point. We want to provide a multi
version installation for our product in the future. We can not
do this without changing the installation folder hierarchy and
naming by one way or the other.

We clearly see the point that the destination folder for the
installation could become optional. However, If we want to
be flexible in the future, we will have big trouble when sticking
to the same flat scheme as it was before. We simply can not do
what we want to do.

What do you think? Are you willing to help us to prepare
Xbase++ for the next steps that lay ahead of us? In case there
are any technical hurdles you can not take - well, just raise
your hands. I am sure you will do 

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:12i3mjqr6z4ij$.1iy2vseo3k3rf.dlg@40tude.net...
> *moved from public.xbase++.generic*
>
> Till Warweg wrote:
>
>> integrated into your personal environment. So it seems to me that in this
>> discussion, we're basically talking about just  the "copying files" part
>> of the installation. Correct?
>
> Yes - basically just give me a ZIP file with all the files and I'm happy
> and shall not bother you again :-)
>
> I don't use neither the workbench nor CXP or the workbench, so I don't 
> need
> all the complicated details that might be built into the installer like 
> IIS
> integration (even don't use IIS).
>
> I tried to use the msiexec /a switch with your installer to put all the
> files into a single location but it does not behave like other msi
> installers I have used in the past - not sure where all the files ended up
> though.
>
> If using the installer, I would also like to deselect the Worksbench -
> which currently is not possible.
>
> And from the "simple user" perspective, putting the selections for CXP,
> environment change and WAA into the "Custom setup" dialog is also not
> optimal:
>
> Because the installer UI is confined to a fixed-size dialog window, there
> are two ugly  scrollbars that make it a pain to select or deslect options
> because you have to scroll around to actually read what every option
> exactly does.
>
> The dialog does not show *where* all the components are actually 
> installed.
>
> I think it would be better to have separate pages with some explanatory
> text what the "special" options like CXP, WAA actually are for.
>
> Especially the important switch for changing the environment gets "lost"
> between all the other options and should have its own page with a checkbox
> to select.
>
>> Your sentiments seem to be different, however, so let's go back to them.
>> I'd like to ask you to put personal feelings  aside (and yeah, I was
>> pi..ed by some of the allegations in this thread!) and talk to us -
>> again!
>
> HA! Actually never stopped talking to you :-)
>
>> The  question that I'm still struggling with is this: supposed the
>> installer gave you that "Choose location" button, and  you'd be able to
>> move the whole folder hierarchy to <my place on drive>, where would you
>> go from there?
>
> I would copy all of those files underneath d:\Alaska\XPP<build number> and
> create a new batch to switch the environment:
>
> @ECHO OFF
> CLS
>
> IF EXIST N:\ SUBST N: /D
> SUBST N: D:\ALASKA\XPP2014
>
> :END
>
> But this assumes the following sub-directory structure:
>
> bin
> book
> Gateway
> include
> lib
> resource
> runtime
> Server
> waa1w32
> WAABase
>
> Of course this does not work if the Alaska files are in seperate base
> directories or even separate drives...
>
>> What about the  environment, file associations etc.?
>
> This is already set up, no need to fiddle with that:
>
> INCLUDE=N:\include
> LIB=N:\LIB;N:\runtime
> Path=N:\Runtime;N:\BIN;N:\LIB;N:\include;
>
> And i don't need any file associations because I do not work from the
> explorer environment but directly from within MultiEdit:
>
> I press F9, <ENTER><ENTER> to compile
> I press F9, <ENTER>,CP <ENTER> to copy the new exe and DLL files over to
> the WAA directory
> I also commit file changes to my Subversion repository from within
> MultiEdit.
>
> Thomas

Andreas,

even if I can understand why Alaska did what they did - in my eyes it is 
horrible that Alaska forces me to do what is right in the eyes of 
Alaska, only in the eyes of Alaska. With all other (professional) 
software I can choose where to install it. Some parts are installed at 
certain places like some dll that are copied to system32. But the main 
software is allways allowed to be installed where I choose. It's only 
Xbase++ that tells me where to install everything.

I am not willing to do so. I am not willing to do such cripple stuff 
like SUBST. I want a professional package that gives me all freedom I 
like to have.

That you changed some folders is no problem for me. I do not understand 
the reasons why but you have them I think. But I have a problem that you 
do not allow me to change the root folder for the whole package.

I also do not understand why the package is departed in so many folders. 
E. g. why are the help fildes in the docs?  They are the docs only for 
Xbase++. So why not install them in the Xbase++ folder? Now I allways 
have to search trough all my folders if I am looking for a specific 
information. libs, help, cxp pages, samples, everything statistily even 
spread.

For me all this is an unnecessary interferrence in my fundamental 
freedom to install my software where ever I want to.

Jan

Am 07.10.2014 um 21:40 schrieb "Andreas Herdt":
> Hi Thomas,
>
> Let me just give some brief answers to some of your remarks:
>
>> I tried to use the msiexec /a switch with your installer to put all the
>> files into a single location but it does not behave like other msi
>> installers I have used in the past - not sure where all the files
>> ended up
>> though.
>
> The ADMIN mode is not supported by the Xbase++ installer. To me
> this seems to be an oversight and should be corrected with a future
> update.
>
>> And from the "simple user" perspective, putting the selections for CXP,
>> environment change and WAA into the "Custom setup" dialog is also not
>> optimal:
>>
>> Because the installer UI is confined to a fixed-size dialog window, there
>> are two ugly scrollbars that make it a pain to select or deslect options
>> because you have to scroll around to actually read what every option
>> exactly does.
>
> Or it is a matter of the installer's UI that just seems not to be large
> enough
> to hold all items without the need of scrollbars. We liked the idea of
> one central place to switch features ON or OFF for installation. This also
> lets you configure/change the installation from the control panels Program
> Settings dialog where you find the option "Change". Disabling the
> Environment feature just removes the environment that might have been
> selected by accident, for example. No other feature is affected in this
> case.
>
>> The dialog does not show where all the components are actually
>> installed.
>
> The idea is that everything is installed at distinct folders. I agree that
> the installer does not tell you that the sources go to
> Documents\Xbase++\..,
> the CXP samples go to wwwroot\websamples (in case an IIS is available)
> and that all binaries go to Programfiles\Alaska Software.
>
>> I think it would be better to have separate pages with some explanatory
>> text what the "special" options like CXP, WAA actually are for.
>
> Don't know what you mean saying "special". These are just optonal features
> you can omit on installation. Clicking each individual feature displays a
> descriptive text what the feature is good for. Here again: There is not
> much
> place to show long text, you have a point here.
>
> I think that the following is your "main" point:
>
>> But this assumes the following sub-directory structure:
>>
>> bin
>> book
>> Gateway
>> include
>> lib
>> resource
>> runtime
>> Server
>
> Am I right that the most pressing issue here is that you can no longer
> switch your environment with respect of the Xbase++ version used
> in the same way you have done before?
>
> To say this first: We as the vendor should be allowed to change the
> details of the folder structure and naming. What was previously named
>
> XPPW32\bin
> XPPW32\lib
> .....
>
> now is named
>
> xpp20\bin
> xpp20\lib
> ....
>
> We also decided to move the online help, the server and other things
> away as these are items that do not necessarily are sticked to a distinct
> version of the development tools
>
> cxp20\bin
> waa20\server
> ....
>
> Insofar not much has been changed in this area.
>
> In case the installer installs the product to an optional folder then
> I would assume this option will be set for the entire product. In
> your case this will mean you will have the following on your drive
> by selecting d:\alaska\xpp2014 as destination folder:
>
> D:\ALASKA\XPP2014\xpp20
> D:\ALASKA\XPP2014\help
> D:\ALASKA\XPP2014\waa20
>
> Your batch file for using that version of Xbase++ would then look
> like this:
>
> ============ snip ==============
> @ECHO OFF
> CLS
>
> IF EXIST N:\ SUBST N: /D
> SUBST N: D:\ALASKA\XPP2014\xpp20
>
> :END
>
> ============ snap ==============
>
> Think about the following 
>
> ============ snip ==============
>   SUBST N: "C:\Program Files\Alaska Software\xpp20"
> ============ snap ==============
>
> Please consider our main point. We want to provide a multi
> version installation for our product in the future. We can not
> do this without changing the installation folder hierarchy and
> naming by one way or the other.
>
> We clearly see the point that the destination folder for the
> installation could become optional. However, If we want to
> be flexible in the future, we will have big trouble when sticking
> to the same flat scheme as it was before. We simply can not do
> what we want to do.
>
> What do you think? Are you willing to help us to prepare
> Xbase++ for the next steps that lay ahead of us? In case there
> are any technical hurdles you can not take - well, just raise
> your hands. I am sure you will do 
>

Hi Jan,

> even if I can understand why Alaska did what they did - in my eyes it is 
> horrible that Alaska forces me to do what is right in the eyes of Alaska, 
> only in the eyes of Alaska. With all other (professional) software I can 
> choose where to install it. Some parts are installed at certain places 
> like some dll that are copied to system32. But the main software is 
> allways allowed to be installed where I choose. It's only Xbase++ that 
> tells me where to install everything.

If I understand you correctly then your topic is to have the option what
the root of the installation is. Currently this is c:\Program Files 
[(x86)]\Alaska Software.
The freedom you want to have is to choose a destination folder, let's say
d:\Alaska. The installer then will install the files to

d:\alaska\xpp20, d:\alaska\cxp20 and so on.

> I am not willing to do so. I am not willing to do such cripple stuff like 
> SUBST. I want a professional package that gives me all freedom I like to 
> have.

That's great. For the time being you just have to deselect the Environment
feature during installation and you do not require to change any drive 
letter
to use the Xbase++ product of choice. You work as usual in
the way you are used to with 1.9. Optionally you can work with 2.0
from the workbench. No SUBST required.

> I also do not understand why the package is departed in so many folders. 
> E. g. why are the help fildes in the docs? They are the docs only for 
> Xbase++. So why not install them in the Xbase++ folder? Now I allways have 
> to search trough all my folders if I am looking for a specific 
> information. libs, help, cxp pages, samples, everything statistily even 
> spread.

Hm, what Xbase++ folder? Do you mean the Xbase++ folder that is
created in the users documents folder? Is this what you expect?

The documentation consolidates everything, not only the Xbase++
development tool and the language. It also contains information about
CXP and WAA for example. Just open xpp-dev.chm, everything is
there.

Just let me understand: The CXP websamples go to wwwroot of an
existing IIS. The sources go to the documents folder. These are the
places where things have to be.

Everything else goes to c:\program files\Alaska Software.

Do you mean this with statistily eve - I think you mean an even 
distribution.

You have distinct menu items with the workbench's help menu to open
the windows explorer in the websamples folder and in the desktop samples
folder.

What else is missing to navigate where you want to in an efficient way?

> For me all this is an unnecessary interferrence in my fundamental freedom 
> to install my software where ever I want to.

So it is about freedom 

Taking joke aside: We have had a lot of trouble where customers of
ours have installed Xbase++ to c:\alaska\ to find out that nothing
worked. Files have vanished, objects could not be written. This does
not behave very professional when trying out a new product.

It is no matter of freedome. Source files by default need to be at a
location where a user has write permissions.

CXP samples need to be at a location where the web server can find
them - there is not much choice here.

Is there anything I do not see? Where is the point you have the impression
that I am ignorant?

Taking all this together: Give me a picture how the installer should
behave from your perspective.

With my best regards,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Jan Escholt" wrote in message 
news:6a4c9c66$1c15ae03$df31@news.alaska-software.com...
> Andreas,
>
> even if I can understand why Alaska did what they did - in my eyes it is 
> horrible that Alaska forces me to do what is right in the eyes of Alaska, 
> only in the eyes of Alaska. With all other (professional) software I can 
> choose where to install it. Some parts are installed at certain places 
> like some dll that are copied to system32. But the main software is 
> allways allowed to be installed where *I* choose. It's only Xbase++ that 
> tells me where to install everything.
>
> I am not willing to do so. I am not willing to do such cripple stuff like 
> SUBST. I want a professional package that gives me all freedom I like to 
> have.
>
> That you changed some folders is no problem for me. I do not understand 
> the reasons why but you have them I think. But I have a problem that you 
> do not allow me to change the root folder for the whole package.
>
> I also do not understand why the package is departed in so many folders. 
> E. g. why are the help fildes in the docs?  They are the docs only for 
> Xbase++. So why not install them in the Xbase++ folder? Now I allways have 
> to search trough all my folders if I am looking for a specific 
> information. libs, help, cxp pages, samples, everything statistily even 
> spread.
>
> For me all this is an unnecessary interferrence in my fundamental freedom 
> to install my software where ever I want to.
>
> Jan
>
> Am 07.10.2014 um 21:40 schrieb "Andreas Herdt":
>> Hi Thomas,
>>
>> Let me just give some brief answers to some of your remarks:
>>
>>> I tried to use the msiexec /a switch with your installer to put all the
>>> files into a single location but it does not behave like other msi
>>> installers I have used in the past - not sure where all the files
>>> ended up
>>> though.
>>
>> The ADMIN mode is not supported by the Xbase++ installer. To me
>> this seems to be an oversight and should be corrected with a future
>> update.
>>
>>> And from the "simple user" perspective, putting the selections for CXP,
>>> environment change and WAA into the "Custom setup" dialog is also not
>>> optimal:
>>>
>>> Because the installer UI is confined to a fixed-size dialog window, 
>>> there
>>> are two ugly scrollbars that make it a pain to select or deslect options
>>> because you have to scroll around to actually read what every option
>>> exactly does.
>>
>> Or it is a matter of the installer's UI that just seems not to be large
>> enough
>> to hold all items without the need of scrollbars. We liked the idea of
>> one central place to switch features ON or OFF for installation. This 
>> also
>> lets you configure/change the installation from the control panels 
>> Program
>> Settings dialog where you find the option "Change". Disabling the
>> Environment feature just removes the environment that might have been
>> selected by accident, for example. No other feature is affected in this
>> case.
>>
>>> The dialog does not show *where* all the components are actually
>>> installed.
>>
>> The idea is that everything is installed at distinct folders. I agree 
>> that
>> the installer does not tell you that the sources go to
>> Documents\Xbase++\..,
>> the CXP samples go to wwwroot\websamples (in case an IIS is available)
>> and that all binaries go to Programfiles\Alaska Software.
>>
>>> I think it would be better to have separate pages with some explanatory
>>> text what the "special" options like CXP, WAA actually are for.
>>
>> Don't know what you mean saying "special". These are just optonal 
>> features
>> you can omit on installation. Clicking each individual feature displays a
>> descriptive text what the feature is good for. Here again: There is not
>> much
>> place to show long text, you have a point here.
>>
>> I think that the following is your "main" point:
>>
>>> But this assumes the following sub-directory structure:
>>>
>>> bin
>>> book
>>> Gateway
>>> include
>>> lib
>>> resource
>>> runtime
>>> Server
>>
>> Am I right that the most pressing issue here is that you can no longer
>> switch your environment with respect of the Xbase++ version used
>> in the same way you have done before?
>>
>> To say this first: We as the vendor should be allowed to change the
>> details of the folder structure and naming. What was previously named
>>
>> XPPW32\bin
>> XPPW32\lib
>> .....
>>
>> now is named
>>
>> xpp20\bin
>> xpp20\lib
>> ....
>>
>> We also decided to move the online help, the server and other things
>> away as these are items that do not necessarily are sticked to a distinct
>> version of the development tools
>>
>> cxp20\bin
>> waa20\server
>> ....
>>
>> Insofar not much has been changed in this area.
>>
>> In case the installer installs the product to an optional folder then
>> I would assume this option will be set for the entire product. In
>> your case this will mean you will have the following on your drive
>> by selecting d:\alaska\xpp2014 as destination folder:
>>
>> D:\ALASKA\XPP2014\xpp20
>> D:\ALASKA\XPP2014\help
>> D:\ALASKA\XPP2014\waa20
>>
>> Your batch file for using that version of Xbase++ would then look
>> like this:
>>
>> ============ snip ==============
>> @ECHO OFF
>> CLS
>>
>> IF EXIST N:\ SUBST N: /D
>> SUBST N: D:\ALASKA\XPP2014\xpp20
>>
>> :END
>>
>> ============ snap ==============
>>
>> Think about the following ;-)
>>
>> ============ snip ==============
>>   SUBST N: "C:\Program Files\Alaska Software\xpp20"
>> ============ snap ==============
>>
>> Please consider our main point. We want to provide a multi
>> version installation for our product in the future. We can not
>> do this without changing the installation folder hierarchy and
>> naming by one way or the other.
>>
>> We clearly see the point that the destination folder for the
>> installation could become optional. However, If we want to
>> be flexible in the future, we will have big trouble when sticking
>> to the same flat scheme as it was before. We simply can not do
>> what we want to do.
>>
>> What do you think? Are you willing to help us to prepare
>> Xbase++ for the next steps that lay ahead of us? In case there
>> are any technical hurdles you can not take - well, just raise
>> your hands. I am sure you will do ;-)
>>

Andreas Herdt wrote:

> Do you mean this with statistily eve - I think you mean an even 
> distribution.

Probably he means "random" 

> So it is about freedom 

Yes, basically that's it.

> Taking all this together: Give me a picture how the installer should
> behave from your perspective.

Just do it as other companies do: Give the user reasonable defaults - but
then leave it up to the user to f*ck it all up and increase your support
fee <eg>

Seriously - I can see you dilemma, but life is not nice to us either - we
are forced into doing nonsense by our customers as well each and every
day of the year 

Thomas

Hi Thomas, Jan, others,

>> Do you mean this with statistily eve - I think you mean an even
>> distribution.
>
> Probably he means "random" 

It is not random. Allthough the behaviour is not inteded, the result is 
deterministic 

Let me summarize what we have learned.

The installer must offer the option to install the product to a folder of 
choice. This affects everything currently installed to "ProgramFiles\Alaska 
Software".

The installer must install the desktop sample collection to the users 
document folder because there the samples can be build.

The installer must install the websamples (CXP) to the document root folder 
of a Web Server if one is available.

With my best regards,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:191bte1xv2od3$.e72zr3lme8ue.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> Do you mean this with statistily eve - I think you mean an even
>> distribution.
>
> Probably he means "random" ;-)
>
>> So it is about freedom ;-)
>
> Yes, basically that's it.
>
>> Taking all this together: Give me a picture how the installer should
>> behave from your perspective.
>
> Just do it as other companies do: Give the user reasonable defaults - but
> then leave it up to the user to f*ck it all up and increase your support
> fee <eg>
>
> Seriously - I can see you dilemma, but life is not nice to us either - we
> are forced into doing nonsense by *our* customers as well each and every
> day of the year :-)
>
> Thomas

Hi Andreas,

Am 10.10.2014 um 09:58 schrieb "Andreas Herdt":
> Let me summarize what we have learned.
>
> The installer must offer the option to install the product to a folder
> of choice. This affects everything currently installed to
> "ProgramFiles\Alaska Software".
>
Agree.

> The installer must install the desktop sample collection to the users
> document folder because there the samples can be build.
>
Why? My problem is if I search for something related with Xbase++ I 
search the Xbase++ folder. Also the samples. And shure I can compile the 
Alaska samples in this folder. Why should't I? So also here I would 
suggest that the installer offers the option to choose my own samples 
folder. Same with the docs ...

> The installer must install the websamples (CXP) to the document root
> folder of a Web Server if one is available.
>
That might be necessary. If not I would prefer to have the option to 
choose my own folder.

Have a nice weekend

Jan

Hello Andreas.
Good afternoon.
Please accept the Jan's suggestions pretty soon.

Friendly
Beling


Em 10/10/2014 14:46, Jan Escholt escreveu:
> Hi Andreas,
>
> Am 10.10.2014 um 09:58 schrieb "Andreas Herdt":
>> Let me summarize what we have learned.
>>
>> The installer must offer the option to install the product to a folder
>> of choice. This affects everything currently installed to
>> "ProgramFiles\Alaska Software".
>>
> Agree.
>
>> The installer must install the desktop sample collection to the users
>> document folder because there the samples can be build.
>>
> Why? My problem is if I search for something related with Xbase++ I
> search the Xbase++ folder. Also the samples. And shure I can compile the
> Alaska samples in this folder. Why should't I? So also here I would
> suggest that the installer offers the option to choose my own samples
> folder. Same with the docs ...
>
>> The installer must install the websamples (CXP) to the document root
>> folder of a Web Server if one is available.
>>
> That might be necessary. If not I would prefer to have the option to
> choose my own folder.
>
> Have a nice weekend
>
> Jan
>

Jan Escholt wrote:

>> The installer must install the desktop sample collection to the users
>> document folder because there the samples can be build.
>>
> Why? My problem is if I search for something related with Xbase++ I 
> search the Xbase++ folder. Also the samples. And shure I can compile the 
> Alaska samples in this folder. Why should't I? 

There are cases where developers don't work with admin rights.

Because the installer runs with "elevated rights" (= AKA administrator) -
no "normal" use has write access to anything below C:\Program Files. 

So you would not be able to build the samples.

Installing software on Windows can be tricky 

Thomas

Thomas,

I believe Jan is right to question why the user's "My Documents" folder is 
the only location, where:

>>The installer must install the desktop sample collection

If I (the user/developer) want to install all Xbase++ files -- including 
the source files -- in a different location, then I would obviously install 
those files where I have access to them and can compile them, if I even want 
to compile them.

If a developer isn't able to figure that out, then he/she has no business of 
developing Windows applications (with Xbase++), IMNSHO. 

So far, I haven't seen a single compelling reason, why Alaska shouldn't or 
couldn't add some sort of expert setting to the Installer, to allow the user 
to install all files at locations of the user's choosing, including the 
source code. 

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

Andreas Gehrs-Pahl wrote:

> If a developer isn't able to figure that out, then he/she has no business of 
> developing Windows applications (with Xbase++), IMNSHO. 

Despite the fact that you are right it also is a fact that there are a lot
of people out there that develop applications without being a developer at
all (like me for example 

Thomas

Andreas Herdt wrote:

> The ADMIN mode is not supported by the Xbase++ installer. To me
> this seems to be an oversight and should be corrected with a future
> update.

The funny thing is that is somehow worked... the installation actually
tried to start the workbench, but this failed probably because things where
not in the right places 

> Or it is a matter of the installer's UI that just seems not to be large 
> enough to hold all items without the need of scrollbars.

Exactly. That is why many other software vendors created specific pages for
distinct features - either to attract special attention or to be able to
format text in a way that is easy to read.

> I think that the following is your "main" point:
> 
>> But this assumes the following sub-directory structure:
>>
>> bin
>> book
[...]

Yes - I have some batches and procedures that rely on that structure.

So just doing what you suggest here:

> 
> Think about the following 
> 
> ============ snip ==============
>   SUBST N: "C:\Program Files\Alaska Software\xpp20"
> ============ snap ==============

Does not solve the problem - for example I would have to create a specific
version of the batch that starts WAA for pre- and post- 2.0 versions.

Since I don't have many different Xbase++ projects, it is not a big problem
for me, I will just change everything and go on. But this discussion
already took a lot of time.

But I also like to speak for my fellow developers that might have a bigger
number of different projects or need to maintain code on different Xbase++
version levels. I can see this structural changes might lead to a lot of
additonal work that is not productive at all.

The easiest way to install Xbase++ for me would be a ZIP file because i
will never use the workbench anyways, so I don't need anything to be
"installed"

> Please consider our main point. We want to provide a multi
> version installation for our product in the future. We can not
> do this without changing the installation folder hierarchy and
> naming by one way or the other.

I see this need for changing naming conventions - but I still do not feel
very comfortable with scattering the various parts of the product all over
the system - I like to have things in a single place.

On the other hand, a document showing where everything gets installed would
help as well.

> We clearly see the point that the destination folder for the
> installation could become optional.

I think optional would be optimal for many of us 

> What do you think? Are you willing to help us to prepare
> Xbase++ for the next steps that lay ahead of us?

Of course - I'm following you since the days of Compuserve 

> In case there are any technical hurdles you can not take - well, just
> raise your hands. I am sure you will do 

You can bet your a**** on that 

back to work
Thomas

Hi Thomas,

> But I also like to speak for my fellow developers that might have a bigger
> number of different projects or need to maintain code on different Xbase++
> version levels. I can see this structural changes might lead to a lot of
> additonal work that is not productive at all.

When we have changed the folder hierarchy and naming we have been aware
of the fact that some of our users must adapt their "drive and environment
managment mechanisms". We have not been able to give clear advices. The
last time when we have observed about 15 Xbase++ programmers managing
their environment, we have found out that rarely they have mechanisms in
common.

> Does not solve the problem - for example I would have to create a specific
> version of the batch that starts WAA for pre- and post- 2.0 versions.

To get a picture - the WAA was in xppw32\server\, it is now in
Alaska Software\waa20\server. You have started the WAA with
n:\server\waa1srv.exe, now you need to start the waa with
n:\waa20\server\waa1srv.exe.

In case you have different batch files to manage different versions of
Xbase++, then you could reserve a distinct drive letter to the waa. In
Xbase++ 1.9 you would start the WAA with o:\waa1srv.exe, a dedicate
drive mapping could subst the drive letter o:\ to a folder that this is
possible with 2.0, too. Is this an approach that would solve the
"two menu entries for online help" issue that you have talked about
in another thread?

>> We clearly see the point that the destination folder for the
>> installation could become optional.
>
> I think optional would be optimal for many of us 

Let us hold this discussion open for some time to give others the 
opportunity
to step in here. For the time being I learned about your needs and the
needs of Jan.

Let us give some time to find out if somebody out there
has trouble with the installation that can not be resolved at all.

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:x1k7vbxjrzhe.tlmlrnhl0t7c$.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> The ADMIN mode is not supported by the Xbase++ installer. To me
>> this seems to be an oversight and should be corrected with a future
>> update.
>
> The funny thing is that is *somehow* worked... the installation actually
> tried to start the workbench, but this failed probably because things 
> where
> not in the right places :-)
>
>> Or it is a matter of the installer's UI that just seems not to be large
>> enough to hold all items without the need of scrollbars.
>
> Exactly. That is why many other software vendors created specific pages 
> for
> distinct features - either to attract special attention or to be able to
> format text in a way that is easy to read.
>
>> I think that the following is your "main" point:
>>
>>> But this assumes the following sub-directory structure:
>>>
>>> bin
>>> book
> [...]
>
> Yes - I have *some* batches and procedures that rely on that structure.
>
> So just doing what you suggest here:
>
>>
>> Think about the following ;-)
>>
>> ============ snip ==============
>>   SUBST N: "C:\Program Files\Alaska Software\xpp20"
>> ============ snap ==============
>
> Does not solve the problem - for example I would have to create a specific
> version of the batch that starts WAA for pre- and post- 2.0 versions.
>
> Since I don't have many different Xbase++ projects, it is not a big 
> problem
> for me, I will just change everything and go on. But this discussion
> already took a lot of time.
>
> But I also like to speak for my fellow developers that might have a bigger
> number of different projects or need to maintain code on different Xbase++
> version levels. I can see this structural changes might lead to a lot of
> additonal work that is not productive at all.
>
> The easiest way to install Xbase++ for *me* would be a ZIP file because i
> will never use the workbench anyways, so I don't need anything to be
> "installed"
>
>> Please consider our main point. We want to provide a multi
>> version installation for our product in the future. We can not
>> do this without changing the installation folder hierarchy and
>> naming by one way or the other.
>
> I see this need for changing naming conventions - but I still do not feel
> very comfortable with scattering the various parts of the product all over
> the system - I like to have things in a single place.
>
> On the other hand, a document showing where everything gets installed 
> would
> help as well.
>
>> We clearly see the point that the destination folder for the
>> installation could become optional.
>
> I think optional would be optimal for many of us ;-)
>
>> What do you think? Are you willing to help us to prepare
>> Xbase++ for the next steps that lay ahead of us?
>
> Of course - I'm following you since the days of Compuserve :-)
>
>> In case there are any technical hurdles you can not take - well, just
>> raise your hands. I am sure you will do ;-)
>
> You can bet your a**** on that <bg>
>
> back to work
> Thomas