Alaska Software Inc. - PBUILD unload of DLL
Username: Password:
AuthorTopic: PBUILD unload of DLL
Al WilsonPBUILD unload of DLL
on Sun, 12 Mar 2017 13:38:32 -0700
In WAA 1.9 there is an environment variable named WAA_DEVMODE in the 
StartWAA.bat file.
With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new 
PBUILD and then the new updated DLL would be loaded.

In WAA 2.0 that environment variable is not supported.
Hence, the DLL has to be unloaded manually from a small scrolling 
drop-down list, then PBUILD has to be run and then the new DLL has to be 
loaded manually.

Is there some way, the 2.0 DLL PBUILD process can be automated to work 
like 1.9?
Please do not advise me to use the workbench.
Thank you for your comments.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Frank GrossheinrichRe: PBUILD unload of DLL
on Thu, 23 Mar 2017 15:46:31 +0100
Hey Al,

It looks like there is a misunderstanding of WAA_DEVMODE.

When the environment WAA_DEVMODE is set then the WAA creates
a copy of the package dll and loads the copy instead of the
original. Before a request is routed to the WAA package function
and if a newer version of the package exists, then the copy
is unloaded and a copy of the new version is loaded instead. So the 
original WAA package is not loaded any time.

The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is 
our understanding and intention.

 > Please do not advise me to use the workbench.
Why? This is not necessary for your issue but working with the Workbench 
is not a bad idea.

For clarification and in case you still encounter the issue while
developing and debugging WAA packages, please get in contact with
support@alaska-software.com.

Kind regards,

Frank

On 12.03.2017 21:38, Al Wilson wrote:
> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
> StartWAA.bat file.
> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
> PBUILD and then the new updated DLL would be loaded.
>
> In WAA 2.0 that environment variable is not supported.
> Hence, the DLL has to be unloaded manually from a small scrolling
> drop-down list, then PBUILD has to be run and then the new DLL has to be
> loaded manually.
>
> Is there some way, the 2.0 DLL PBUILD process can be automated to work
> like 1.9?
> Please do not advise me to use the workbench.
> Thank you for your comments.
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
Al WilsonRe: PBUILD unload of DLL
on Thu, 23 Mar 2017 08:47:55 -0700
Thank you, Frank, for explaining WAA_DEVMODE.

My observation is that PBUILD in 2.0 does not behave the same as 1.9.

If I were to adopt the workbench then my system which has worked 
extemely well for the past 17 years would need to be abandoned.
I do not see a benefit in that course of action.

Why is WAA_DEVMODE not supported in 2.0?

On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
> Hey Al,
>
> It looks like there is a misunderstanding of WAA_DEVMODE.
>
> When the environment WAA_DEVMODE is set then the WAA creates
> a copy of the package dll and loads the copy instead of the
> original. Before a request is routed to the WAA package function
> and if a newer version of the package exists, then the copy
> is unloaded and a copy of the new version is loaded instead. So the
> original WAA package is not loaded any time.
>
> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
> our understanding and intention.
>
>> Please do not advise me to use the workbench.
> Why? This is not necessary for your issue but working with the Workbench
> is not a bad idea.
>
> For clarification and in case you still encounter the issue while
> developing and debugging WAA packages, please get in contact with
> support@alaska-software.com.
>
> Kind regards,
>
> Frank
>
> On 12.03.2017 21:38, Al Wilson wrote:
>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>> StartWAA.bat file.
>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>> PBUILD and then the new updated DLL would be loaded.
>>
>> In WAA 2.0 that environment variable is not supported.
>> Hence, the DLL has to be unloaded manually from a small scrolling
>> drop-down list, then PBUILD has to be run and then the new DLL has to be
>> loaded manually.
>>
>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>> like 1.9?
>> Please do not advise me to use the workbench.
>> Thank you for your comments.
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Frank GrossheinrichRe: PBUILD unload of DLL
on Fri, 24 Mar 2017 15:03:49 +0100
Hey Al,

hope I was not that misleading ... but apparently I was: WAA_DEVMODE is 
definitely working. I took the time and tested it personally. So it is 
still there and usable! And works as I described. I started WAA with the 
environment variable set to ON, changed some code of one of the sample 
packages, built the package and called the WAA function again and all is 
in proper shape. WAA internally unloaded the ~package, copied the new 
built DLL to ~package a did load it again and fired its code.

Please check on your own: as soon you run WAA in WAA_DEVMODE and you 
load the package you will get a copy of the DLL in the very same 
directory prefixed with a tilde (~). If not, you are not running in 
WAA_DEVMODE.

So I would take a look at the DLL (the package) itself. Can you 
dynamically unload it? Does the package load other DLLs? Can those be 
unloaded? You get the picture?

If you are still stuck, please get in contact with my colleagues at 
Technical Support. They are extremely interested in that issue.

Regards, Frank

On 23.03.2017 16:47, Al Wilson wrote:
> Thank you, Frank, for explaining WAA_DEVMODE.
>
> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>
> If I were to adopt the workbench then my system which has worked
> extemely well for the past 17 years would need to be abandoned.
> I do not see a benefit in that course of action.
>
> Why is WAA_DEVMODE not supported in 2.0?
>
> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>> Hey Al,
>>
>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>
>> When the environment WAA_DEVMODE is set then the WAA creates
>> a copy of the package dll and loads the copy instead of the
>> original. Before a request is routed to the WAA package function
>> and if a newer version of the package exists, then the copy
>> is unloaded and a copy of the new version is loaded instead. So the
>> original WAA package is not loaded any time.
>>
>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>> our understanding and intention.
>>
>>> Please do not advise me to use the workbench.
>> Why? This is not necessary for your issue but working with the Workbench
>> is not a bad idea.
>>
>> For clarification and in case you still encounter the issue while
>> developing and debugging WAA packages, please get in contact with
>> support@alaska-software.com.
>>
>> Kind regards,
>>
>> Frank
>>
>> On 12.03.2017 21:38, Al Wilson wrote:
>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>> StartWAA.bat file.
>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>>> PBUILD and then the new updated DLL would be loaded.
>>>
>>> In WAA 2.0 that environment variable is not supported.
>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>> drop-down list, then PBUILD has to be run and then the new DLL has to be
>>> loaded manually.
>>>
>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>> like 1.9?
>>> Please do not advise me to use the workbench.
>>> Thank you for your comments.
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
Al WilsonRe: PBUILD unload of DLL
on Fri, 24 Mar 2017 08:34:04 -0700
Hi Frank:

WAA_DEVMODE is set to on.
WAA loads eleven DLLs.
There are no prefixed ~DLL copies created in the same directory.
Any DLL can be dynamically unloaded and reloaded.
Each DLL loads a library file via #pragma in the _Register(oPackage) 
function

Why does the 2.0 documentation say that WAA_DEVMODE is not supported?
Is the WAA behaviour directory-specific?

I have also sent this message to Technical Support.

On 3/24/17 7:03 AM, Frank Grossheinrich wrote:
> Hey Al,
>
> hope I was not that misleading ... but apparently I was: WAA_DEVMODE is
> definitely working. I took the time and tested it personally. So it is
> still there and usable! And works as I described. I started WAA with the
> environment variable set to ON, changed some code of one of the sample
> packages, built the package and called the WAA function again and all is
> in proper shape. WAA internally unloaded the ~package, copied the new
> built DLL to ~package a did load it again and fired its code.
>
> Please check on your own: as soon you run WAA in WAA_DEVMODE and you
> load the package you will get a copy of the DLL in the very same
> directory prefixed with a tilde (~). If not, you are not running in
> WAA_DEVMODE.
>
> So I would take a look at the DLL (the package) itself. Can you
> dynamically unload it? Does the package load other DLLs? Can those be
> unloaded? You get the picture?
>
> If you are still stuck, please get in contact with my colleagues at
> Technical Support. They are extremely interested in that issue.
>
> Regards, Frank
>
> On 23.03.2017 16:47, Al Wilson wrote:
>> Thank you, Frank, for explaining WAA_DEVMODE.
>>
>> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>>
>> If I were to adopt the workbench then my system which has worked
>> extemely well for the past 17 years would need to be abandoned.
>> I do not see a benefit in that course of action.
>>
>> Why is WAA_DEVMODE not supported in 2.0?
>>
>> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>>> Hey Al,
>>>
>>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>>
>>> When the environment WAA_DEVMODE is set then the WAA creates
>>> a copy of the package dll and loads the copy instead of the
>>> original. Before a request is routed to the WAA package function
>>> and if a newer version of the package exists, then the copy
>>> is unloaded and a copy of the new version is loaded instead. So the
>>> original WAA package is not loaded any time.
>>>
>>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>>> our understanding and intention.
>>>
>>>> Please do not advise me to use the workbench.
>>> Why? This is not necessary for your issue but working with the Workbench
>>> is not a bad idea.
>>>
>>> For clarification and in case you still encounter the issue while
>>> developing and debugging WAA packages, please get in contact with
>>> support@alaska-software.com.
>>>
>>> Kind regards,
>>>
>>> Frank
>>>
>>> On 12.03.2017 21:38, Al Wilson wrote:
>>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>>> StartWAA.bat file.
>>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>>>> PBUILD and then the new updated DLL would be loaded.
>>>>
>>>> In WAA 2.0 that environment variable is not supported.
>>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>>> drop-down list, then PBUILD has to be run and then the new DLL has
>>>> to be
>>>> loaded manually.
>>>>
>>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>>> like 1.9?
>>>> Please do not advise me to use the workbench.
>>>> Thank you for your comments.
>>>>
>>>> ---
>>>> This email has been checked for viruses by Avast antivirus software.
>>>> https://www.avast.com/antivirus
>>>>
>>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Frank GrossheinrichRe: PBUILD unload of DLL
on Fri, 24 Mar 2017 17:24:24 +0100
Hey Al,

??? Where did you find that WAA_DEVMODE is not supported? I checked the 
docs and cannot find it. Please advise. As I said before: I tested it. 
And it should be supported.

Could you please try one of the Alaska WAA samples first? I would like 
to reduce complexity.

What DLLs are your packages additionally loading? Plain Xbase++? Your 
DLLs or third party?

How do you prove that they can be unloaded? Can you rename the file on 
the disc when unloaded? Could you check this for each package?

Regards, Frank

PS: it gets too complex to discuss in public (even I try to) but it 
might make more sense that my colleagues will dig into this.

On 24.03.2017 16:34, Al Wilson wrote:
> Hi Frank:
>
> WAA_DEVMODE is set to on.
> WAA loads eleven DLLs.
> There are no prefixed ~DLL copies created in the same directory.
> Any DLL can be dynamically unloaded and reloaded.
> Each DLL loads a library file via #pragma in the _Register(oPackage)
> function
>
> Why does the 2.0 documentation say that WAA_DEVMODE is not supported?
> Is the WAA behaviour directory-specific?
>
> I have also sent this message to Technical Support.
>
> On 3/24/17 7:03 AM, Frank Grossheinrich wrote:
>> Hey Al,
>>
>> hope I was not that misleading ... but apparently I was: WAA_DEVMODE is
>> definitely working. I took the time and tested it personally. So it is
>> still there and usable! And works as I described. I started WAA with the
>> environment variable set to ON, changed some code of one of the sample
>> packages, built the package and called the WAA function again and all is
>> in proper shape. WAA internally unloaded the ~package, copied the new
>> built DLL to ~package a did load it again and fired its code.
>>
>> Please check on your own: as soon you run WAA in WAA_DEVMODE and you
>> load the package you will get a copy of the DLL in the very same
>> directory prefixed with a tilde (~). If not, you are not running in
>> WAA_DEVMODE.
>>
>> So I would take a look at the DLL (the package) itself. Can you
>> dynamically unload it? Does the package load other DLLs? Can those be
>> unloaded? You get the picture?
>>
>> If you are still stuck, please get in contact with my colleagues at
>> Technical Support. They are extremely interested in that issue.
>>
>> Regards, Frank
>>
>> On 23.03.2017 16:47, Al Wilson wrote:
>>> Thank you, Frank, for explaining WAA_DEVMODE.
>>>
>>> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>>>
>>> If I were to adopt the workbench then my system which has worked
>>> extemely well for the past 17 years would need to be abandoned.
>>> I do not see a benefit in that course of action.
>>>
>>> Why is WAA_DEVMODE not supported in 2.0?
>>>
>>> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>>>> Hey Al,
>>>>
>>>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>>>
>>>> When the environment WAA_DEVMODE is set then the WAA creates
>>>> a copy of the package dll and loads the copy instead of the
>>>> original. Before a request is routed to the WAA package function
>>>> and if a newer version of the package exists, then the copy
>>>> is unloaded and a copy of the new version is loaded instead. So the
>>>> original WAA package is not loaded any time.
>>>>
>>>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>>>> our understanding and intention.
>>>>
>>>>> Please do not advise me to use the workbench.
>>>> Why? This is not necessary for your issue but working with the
>>>> Workbench
>>>> is not a bad idea.
>>>>
>>>> For clarification and in case you still encounter the issue while
>>>> developing and debugging WAA packages, please get in contact with
>>>> support@alaska-software.com.
>>>>
>>>> Kind regards,
>>>>
>>>> Frank
>>>>
>>>> On 12.03.2017 21:38, Al Wilson wrote:
>>>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>>>> StartWAA.bat file.
>>>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a
>>>>> new
>>>>> PBUILD and then the new updated DLL would be loaded.
>>>>>
>>>>> In WAA 2.0 that environment variable is not supported.
>>>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>>>> drop-down list, then PBUILD has to be run and then the new DLL has
>>>>> to be
>>>>> loaded manually.
>>>>>
>>>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>>>> like 1.9?
>>>>> Please do not advise me to use the workbench.
>>>>> Thank you for your comments.
>>>>>
>>>>> ---
>>>>> This email has been checked for viruses by Avast antivirus software.
>>>>> https://www.avast.com/antivirus
>>>>>
>>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
Frank GrossheinrichRe: PBUILD unload of DLL
on Fri, 24 Mar 2017 17:35:02 +0100
Hi Al,

back to the "I do not want the Workbench": I cannot live without it. 
Even with my WAA and CXP development. Yes! Not for code writing reasons, 
but for debugging reasons.

Although debugging is for bad programmers only .

Did you find in the Workbench
- have your package DLL in the Workbench
- Run
- Parameter
- Host Application

setting? Please put in there your WAA1SRV.EXE (with entire path; please 
use the box beside the entry field and navigate to your EXE). Have the 
package DLL which you like to debug as active target, press F8 or F10 
and start debugging the package. WAA will start in the background and 
you start your debugging session.

Beside that you'll get notified of updates via the Workbench. And there 
are every 1-2 months.

Regards, Frank

On 23.03.2017 16:47, Al Wilson wrote:
> Thank you, Frank, for explaining WAA_DEVMODE.
>
> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>
> If I were to adopt the workbench then my system which has worked
> extemely well for the past 17 years would need to be abandoned.
> I do not see a benefit in that course of action.
>
> Why is WAA_DEVMODE not supported in 2.0?
>
> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>> Hey Al,
>>
>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>
>> When the environment WAA_DEVMODE is set then the WAA creates
>> a copy of the package dll and loads the copy instead of the
>> original. Before a request is routed to the WAA package function
>> and if a newer version of the package exists, then the copy
>> is unloaded and a copy of the new version is loaded instead. So the
>> original WAA package is not loaded any time.
>>
>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>> our understanding and intention.
>>
>>> Please do not advise me to use the workbench.
>> Why? This is not necessary for your issue but working with the Workbench
>> is not a bad idea.
>>
>> For clarification and in case you still encounter the issue while
>> developing and debugging WAA packages, please get in contact with
>> support@alaska-software.com.
>>
>> Kind regards,
>>
>> Frank
>>
>> On 12.03.2017 21:38, Al Wilson wrote:
>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>> StartWAA.bat file.
>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>>> PBUILD and then the new updated DLL would be loaded.
>>>
>>> In WAA 2.0 that environment variable is not supported.
>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>> drop-down list, then PBUILD has to be run and then the new DLL has to be
>>> loaded manually.
>>>
>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>> like 1.9?
>>> Please do not advise me to use the workbench.
>>> Thank you for your comments.
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
Al WilsonRe: PBUILD unload of DLL
on Mon, 27 Mar 2017 12:06:45 -0700
Hi Frank:
If you cannot live without the workbench then you are new to WAA 
development.
I do not need the workbench for debugging WAA code.
I looked at the workbench and it doesn't do anything to increase my 
efficiency or my productiviy.

I appreciate that Alaska invested significant resources into a tool that 
has no value for me.
Maybe if the workbench had been developed before I started with WAA, 
then I might have found it useful.
However, the workbench arrived 17 years too late for me.

There is no room to enhance my existing WAA development procedures via a 
workbench.
The workbench looks like an valuable tool for Xbase++ which I don't use.
WAA doesn't create EXE files.

On 3/24/17 9:35 AM, Frank Grossheinrich wrote:
> Hi Al,
>
> back to the "I do not want the Workbench": I cannot live without it.
> Even with my WAA and CXP development. Yes! Not for code writing reasons,
> but for debugging reasons.
>
> Although debugging is for bad programmers only .
>
> Did you find in the Workbench
> - have your package DLL in the Workbench
> - Run
> - Parameter
> - Host Application
>
> setting? Please put in there your WAA1SRV.EXE (with entire path; please
> use the box beside the entry field and navigate to your EXE). Have the
> package DLL which you like to debug as active target, press F8 or F10
> and start debugging the package. WAA will start in the background and
> you start your debugging session.
>
> Beside that you'll get notified of updates via the Workbench. And there
> are every 1-2 months.
>
> Regards, Frank
>
> On 23.03.2017 16:47, Al Wilson wrote:
>> Thank you, Frank, for explaining WAA_DEVMODE.
>>
>> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>>
>> If I were to adopt the workbench then my system which has worked
>> extemely well for the past 17 years would need to be abandoned.
>> I do not see a benefit in that course of action.
>>
>> Why is WAA_DEVMODE not supported in 2.0?
>>
>> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>>> Hey Al,
>>>
>>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>>
>>> When the environment WAA_DEVMODE is set then the WAA creates
>>> a copy of the package dll and loads the copy instead of the
>>> original. Before a request is routed to the WAA package function
>>> and if a newer version of the package exists, then the copy
>>> is unloaded and a copy of the new version is loaded instead. So the
>>> original WAA package is not loaded any time.
>>>
>>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>>> our understanding and intention.
>>>
>>>> Please do not advise me to use the workbench.
>>> Why? This is not necessary for your issue but working with the Workbench
>>> is not a bad idea.
>>>
>>> For clarification and in case you still encounter the issue while
>>> developing and debugging WAA packages, please get in contact with
>>> support@alaska-software.com.
>>>
>>> Kind regards,
>>>
>>> Frank
>>>
>>> On 12.03.2017 21:38, Al Wilson wrote:
>>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>>> StartWAA.bat file.
>>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a new
>>>> PBUILD and then the new updated DLL would be loaded.
>>>>
>>>> In WAA 2.0 that environment variable is not supported.
>>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>>> drop-down list, then PBUILD has to be run and then the new DLL has
>>>> to be
>>>> loaded manually.
>>>>
>>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>>> like 1.9?
>>>> Please do not advise me to use the workbench.
>>>> Thank you for your comments.
>>>>
>>>> ---
>>>> This email has been checked for viruses by Avast antivirus software.
>>>> https://www.avast.com/antivirus
>>>>
>>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Frank GrossheinrichRe: PBUILD unload of DLL
on Thu, 30 Mar 2017 11:30:27 +0200
Al,

no, not really: I am not new to WAA development. One of my first 
projects was the DTS (aka WebKB, Knowledgebase) at Alaska Software. This 
was end of 90s.

And the Workbench improved my productivity, my turnaround cycles, my 
debugging, my coding, my tools, my project management, my build 
processing, my environment, my ... everything.

Anyhow, I do not want to convince you. This is also good with Xbase++: 
you can work as you did the last 20 years (use MultiEdit, command line, 
...). Use what you are used to.

I personally use the Workbench and I am VERY happy with it. Especially I 
know what I missed 20 years ago.

Regards, Frank



On 27.03.2017 21:06, Al Wilson wrote:
> Hi Frank:
> If you cannot live without the workbench then you are new to WAA
> development.
> I do not need the workbench for debugging WAA code.
> I looked at the workbench and it doesn't do anything to increase my
> efficiency or my productiviy.
>
> I appreciate that Alaska invested significant resources into a tool that
> has no value for me.
> Maybe if the workbench had been developed before I started with WAA,
> then I might have found it useful.
> However, the workbench arrived 17 years too late for me.
>
> There is no room to enhance my existing WAA development procedures via a
> workbench.
> The workbench looks like an valuable tool for Xbase++ which I don't use.
> WAA doesn't create EXE files.
>
> On 3/24/17 9:35 AM, Frank Grossheinrich wrote:
>> Hi Al,
>>
>> back to the "I do not want the Workbench": I cannot live without it.
>> Even with my WAA and CXP development. Yes! Not for code writing reasons,
>> but for debugging reasons.
>>
>> Although debugging is for bad programmers only .
>>
>> Did you find in the Workbench
>> - have your package DLL in the Workbench
>> - Run
>> - Parameter
>> - Host Application
>>
>> setting? Please put in there your WAA1SRV.EXE (with entire path; please
>> use the box beside the entry field and navigate to your EXE). Have the
>> package DLL which you like to debug as active target, press F8 or F10
>> and start debugging the package. WAA will start in the background and
>> you start your debugging session.
>>
>> Beside that you'll get notified of updates via the Workbench. And there
>> are every 1-2 months.
>>
>> Regards, Frank
>>
>> On 23.03.2017 16:47, Al Wilson wrote:
>>> Thank you, Frank, for explaining WAA_DEVMODE.
>>>
>>> My observation is that PBUILD in 2.0 does not behave the same as 1.9.
>>>
>>> If I were to adopt the workbench then my system which has worked
>>> extemely well for the past 17 years would need to be abandoned.
>>> I do not see a benefit in that course of action.
>>>
>>> Why is WAA_DEVMODE not supported in 2.0?
>>>
>>> On 3/23/17 7:46 AM, Frank Grossheinrich wrote:
>>>> Hey Al,
>>>>
>>>> It looks like there is a misunderstanding of WAA_DEVMODE.
>>>>
>>>> When the environment WAA_DEVMODE is set then the WAA creates
>>>> a copy of the package dll and loads the copy instead of the
>>>> original. Before a request is routed to the WAA package function
>>>> and if a newer version of the package exists, then the copy
>>>> is unloaded and a copy of the new version is loaded instead. So the
>>>> original WAA package is not loaded any time.
>>>>
>>>> The WAA 2.0 behaves exactly as the WAA in version 1.9. At least this is
>>>> our understanding and intention.
>>>>
>>>>> Please do not advise me to use the workbench.
>>>> Why? This is not necessary for your issue but working with the
>>>> Workbench
>>>> is not a bad idea.
>>>>
>>>> For clarification and in case you still encounter the issue while
>>>> developing and debugging WAA packages, please get in contact with
>>>> support@alaska-software.com.
>>>>
>>>> Kind regards,
>>>>
>>>> Frank
>>>>
>>>> On 12.03.2017 21:38, Al Wilson wrote:
>>>>> In WAA 1.9 there is an environment variable named WAA_DEVMODE in the
>>>>> StartWAA.bat file.
>>>>> With "SET WAA_DEVMODE=ON" any loaded DLL would be unloaded during a
>>>>> new
>>>>> PBUILD and then the new updated DLL would be loaded.
>>>>>
>>>>> In WAA 2.0 that environment variable is not supported.
>>>>> Hence, the DLL has to be unloaded manually from a small scrolling
>>>>> drop-down list, then PBUILD has to be run and then the new DLL has
>>>>> to be
>>>>> loaded manually.
>>>>>
>>>>> Is there some way, the 2.0 DLL PBUILD process can be automated to work
>>>>> like 1.9?
>>>>> Please do not advise me to use the workbench.
>>>>> Thank you for your comments.
>>>>>
>>>>> ---
>>>>> This email has been checked for viruses by Avast antivirus software.
>>>>> https://www.avast.com/antivirus
>>>>>
>>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
Thomas BraunRe: PBUILD unload of DLL
on Sat, 01 Apr 2017 13:21:26 +0200
Al Wilson wrote:

> In WAA 2.0 that environment variable is not supported.

I don't know if this is true since I haven't been using this feature for a
long time

> Is there some way, the 2.0 DLL PBUILD process can be automated to work 
> like 1.9?

Yes, there is. Hope the code below makes sense 

When Starting WAA, I am starting an additional thread that watches the WAA
directory for a "quit.txt" file, then restarts the server. The important
point is - I'm also using this to update the production server via SFTP
upload.

I'm using MultiEdit, after building the WAA DLLs, I call the following copy
job, which stops the WAA and copies the new DLLs as soon as they are
accessible - the PINGs are just creating a delay that gives the server a
chance to unload:

@ECHO OFF
COPY quit.txt N:\server > NUL
COPY quit.txt N:\server\restart.txt > NUL
ping -n 2 127.0.0.1 > NUL
pathping -n -p 1000 -q 1 127.0.0.1 > NUL
REPLACE *.DLL \wwwroot\hp10 /U /R

The WAA start batch looks like this:

REM File: STARTWAA.BAT
REM
REM Purpose: Setting environment variables for
REM          WAA1SRV.EXE
REM

COPY waaKonfig-14.cfg waa1srv.cfg
SET WAA_WORKERTHREADS=5
SET WAA_HOST=localhost
SET WAA_PORT=2024
SET WAA_TRACE=ON
SET WAA_DEVMODE=OFF
SET WAA_INTERNAL_LOG=ON
SET WAA_MAILERROR=ON
SET WAA_CC_TEST=ON
SET WAA_CC_LOG=ON
SET WAA_XML_EXPORT=ON
SET WAA_LOCK_RETRY=1000000
SET WAA_RESTART_INTERVAL=
SET WAA_UPLOAD_HOST=elws021

:restart
IF EXIST restart.txt DEL RESTART.TXT
%1 waa1srv.exe

PING 127.0.0.1 -n 2 > NUL
IF EXIST restart.txt GOTO restart
IF EXIST update.txt GOTO update
GOTO end

:update
GOTO restart

:end


The code that checks for the quit file:

(WAA_CheckForQuitThread() is called from my INIT PROCEDURE ApplicationInit)

Function WAA_CheckForQuitThread()
LOCAL oThread

   FERASE(".\quit.txt")
   WriteToLogScreen( "Starting quitter thread...")
   oThread := Thread():New()
   oThread:SetInterval(200)
   oThread:SetPriority(PRIORITY_LOWEST)
   oThread:Start({|| CheckForQuitTxt() })

RETURN NIL

FUNCTION CheckForQuitTxt

   IF FEXISTS(".\quit.txt")
      WriteToLogScreen( "Quitting WAA...")
      MyPersonalShutdown()
   ENDIF

RETURN NIL

FUNCTION MyPersonalShutdown()
LOCAL oS := ClassObject("session")

    wichtig fuer session persistence
    oS:notifyDllUnload()

    startet den eigentliche shutdown
    &("shutdown")()
RETURN NIL