We have several forms in our application using the XbpHtmlViewer. (xbase 1.9 
and 2.0)

After a while using the application and opening and closing the 
xbphtmlviewer (destroy object, etc) 
we get random Not enough memory error's.

If we don't use the control in our tests we don't see the memory usage of 
the application growing and neither do we see the not enough memory error's.

Memory isn't released by the webbrowser control. Some simple googling 
"webbrowser memory leak" you find a lot of projects having the same issue.

Has anybody found a good solution ?
Is there any suggestion for an alternative ? 
Has somebody builded a wrapper around chromium/other browsers ? 

Kind regards,Nico

Nico Houben wrote in
news:6502c77d$4fb5af32$1bedea@news.alaska-software.com: 

> Memory isn't released by the webbrowser control. Some simple googling 
> "webbrowser memory leak" you find a lot of projects having the same
> issue. 

I don't know about memory leak, but I tried using the XbpHtmlViewer many 
years ago and found lots of other issues which ended up wasting my time. It 
was simply not usable. For example, scanning a 20 digit barcode into a edit 
field would occasionally result in lost characters. The problem was the 
fast data input. Typing the data in was OK, but scanning resulted in 
errors.
 
> Has anybody found a good solution ?
> Is there any suggestion for an alternative ? 

The solution in our case was to abandon use of XbpHtmlViewer (as well as 
all other Xbase++ GUI components). We use the Xb2.NET library to create an 
HTTP service and launch the entire GUI in a standard web browser. This was 
the best decision ever, because now our GUI can run on any client (PC, 
tablet, mobile,...) and our clients consider the interface & architecture 
to be very modern.

Best regards,
Boris Borzic

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

Boris Borzic wrote in message 
>Nico Houben wrote in
>news:6502c77d$4fb5af32$1bedea@news.alaska-software.com: 
>
>The solution in our case was to abandon use of XbpHtmlViewer (as well as 
>all other Xbase++ GUI components). We use the Xb2.NET library to create an 
>HTTP service and launch the entire GUI in a standard web browser. This was 
>the best decision ever, because now our GUI can run on any client (PC, 
>tablet, mobile,...) and our clients consider the interface & architecture 
>to be very modern.
I which we knew this 10 yrs ago.
I use your library for many other things like consuming webservices for several 
years now, and also to make an SMTP-SSL client for Xbase 1.9

We still love it and now use it in 1.9 and 2.0

Thanks for makeing this library.

On 3/27/2018 10:54 AM, Nico Houben wrote:
> We have several forms in our application using the XbpHtmlViewer. (xbase 1.9
> and 2.0)
>
> After a while using the application and opening and closing the
> xbphtmlviewer (destroy object, etc)
> we get random Not enough memory error's.
>
> If we don't use the control in our tests we don't see the memory usage of
> the application growing and neither do we see the not enough memory error's.
>
> Memory isn't released by the webbrowser control. Some simple googling
> "webbrowser memory leak" you find a lot of projects having the same issue.
>
> Has anybody found a good solution ?
> Is there any suggestion for an alternative ?
> Has somebody builded a wrapper around chromium/other browsers ?
>
> Kind regards,Nico
>

Nico,

Be sure to destroy both the xbpHtmlViewer object and the parent window 
object when window is closed.  Otherwise, a lot of memory may be left in 
use.

Also, be aware that by default the xbpHtmlViewer object uses an older 
version IE that might not handle memory as efficiently as the newer 
versions.  There is a registry setting you can configure that will force 
your application to use the latest version of IE when the xbpHtmlViewer 
object is created.  Here is a link that provides a lot of good 
information on the registry settings - 
https://weblog.west-wind.com/posts/2011/may/21/web-browser-control-specifying-the-ie-version

I hope this helps.  Good luck!

Chris Carmac

Chris Carmac <ccarmac@freedomsoft.info> wrote in message news:8b98149$4a0fe919
$1f380d@news.alaska-software.com...
>On 3/27/2018 10:54 AM, Nico Houben wrote:
>
>Be sure to destroy both the xbpHtmlViewer object and the parent window 
>object when window is closed.  Otherwise, a lot of memory may be left in 
>use.
>
>Also, be aware that by default the xbpHtmlViewer object uses an older 
>version IE that might not handle memory as efficiently as the newer 
>versions.  There is a registry setting you can configure that will force 
>your application to use the latest version of IE when the xbpHtmlViewer 
>object is created.  Here is a link that provides a lot of good 
>information on the registry settings - 
>https://weblog.west-wind.com/posts/2011/may/21/web-browser-control-specifying-
the-ie-version
>
Did this already but still the same.

On 3/27/2018 10:54 AM, Nico Houben wrote:
> We have several forms in our application using the XbpHtmlViewer. (xbase 1.9
> and 2.0)
>
> After a while using the application and opening and closing the
> xbphtmlviewer (destroy object, etc)
> we get random Not enough memory error's.
>
> If we don't use the control in our tests we don't see the memory usage of
> the application growing and neither do we see the not enough memory error's.
>
> Memory isn't released by the webbrowser control. Some simple googling
> "webbrowser memory leak" you find a lot of projects having the same issue.
>
> Has anybody found a good solution ?
> Is there any suggestion for an alternative ?
> Has somebody builded a wrapper around chromium/other browsers ?
>
> Kind regards,Nico
>

Nico,

In my previous post I forgot to mention that another approach would be 
to create an Internet Explorer object and use that instead of the 
xbpHtmlViewer object.  You can create the object like this...

oIE := CreateObject("InternetExplorer.Application") 	

I have attached a small code sample that shows an example of how I 
create this object and use it.  Hopefully, it will give you an idea or two.

Chris

Chris Carmac <ccarmac@freedomsoft.info> wrote in message news:e9e07d5$6ae62651
$2c6283@news.alaska-software.com...
>In my previous post I forgot to mention that another approach would be 
>to create an Internet Explorer object and use that instead of the 
>xbpHtmlViewer object.  You can create the object like this...
>
>oIE := CreateObject("InternetExplorer.Application") 	
>
>I have attached a small code sample that shows an example of how I 
>create this object and use it.  Hopefully, it will give you an idea or two.
>
I'll give this one a shot.

Seeing your code made me curious, and I discovered we are developing both 
software for the "car/tyre-repairshop". 
We do this in the Netherlands now and are working on a European version now.

Nico

Nico:

Have you tried to execute :navigate( 'about:blank') before the destroy 
method?

See the sample.

Regards. Diego

Nico,

please contact our Technical Support team.
I had a very brief discussion with them while lunch  and they do not 
think this is related to XbpHtmlViewer (which is an ActiveX control). So 
maybe they can help here. At least we are interested in any momory 
consuming issue!

Finally, if you are willing completely to re-write your application to a 
web application which entirely runs into a browser - as Boris suggested 
- you could use HttpEndpoint() and a WebHandler() and you do not need 
any 3rd party product. It's all Xbase++.

Regards
Frank

On 27.03.2018 16:54, Nico Houben wrote:
> We have several forms in our application using the XbpHtmlViewer. (xbase 1.9
> and 2.0)
>
> After a while using the application and opening and closing the
> xbphtmlviewer (destroy object, etc)
> we get random Not enough memory error's.
>
> If we don't use the control in our tests we don't see the memory usage of
> the application growing and neither do we see the not enough memory error's.
>
> Memory isn't released by the webbrowser control. Some simple googling
> "webbrowser memory leak" you find a lot of projects having the same issue.
>
> Has anybody found a good solution ?
> Is there any suggestion for an alternative ?
> Has somebody builded a wrapper around chromium/other browsers ?
>
> Kind regards,Nico
>

Frank Grossheinrich wrote in
news:368b45cb$7558fe88$35c254@news.alaska-software.com: 

> Finally, if you are willing completely to re-write your application to
> a web application which entirely runs into a browser - as Boris
> suggested - you could use HttpEndpoint() and a WebHandler() and you do
> not need any 3rd party product. It's all Xbase++.


Frank: I'm terribly sorry but I must ask. Is this the Alaska Software 
strategy now? 

Improving the core compiler is too difficult so you start cannibalizing
your 3rd party technology "partners" for ideas and developing competing
products. Kindly explain this to me, because I just don't get it! 

Your 3rd party "partners" are not stealing customers from you. Every 
single one, 100% of my customers is also an Xbase++ user and an Alaska
Software customer. To make your product better, you need to 
support/encourage your "partners" not compete against them. Doing
otherwise is a fool's strategy. 

Furthermore, Xb2.NET was released in 2002 - that's 16 years ago. During 
this time it has been continually enhanced and improved. It is an 
incredibly robust and stable library! It is a disservice to your users 
and customers to suggest that your new competing 'beta' product is 
somehow superior. 

We use Xb2.NET in our own DivertCode warehouse automation software where 
it runs 24/7 under extremely demanding conditions (using Xbase++ 
1.90.355). Not only is this a testament to how good Xb2.NET is, but is 
also a testament to how good the Xbase++ compiler is. That core compiler
however is now quite old and very little has been done in Xbase++ 2.0 to
improve it. This is one reason why we continue to use 1.90 in our own
production environments (FYI, both SQLExpress + Xb2.NET support Xbase++ 
1.82 - 2.0). 

Nevertheless, I am supporting you with my annual subscription to Xbase++
2.0. Though to be quite honest, between SQLExpress and Xb2.NET there is
little compelling reason for me to use Xbase++ 2.0 or any of the "new"
stuff that has been added to it. I do hope that a small portion of my
annual contribution will be well spent in enhancing the core compiler
and expanding the user base. 

Sincerely,
Boris Borzic

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

Hey Boris,

hmmmm, I would like to express my completely un-technically feeling that 
I am not very happy with your attitude towards Xbase++ and Alaska 
Software. I often think that you do not value a partnership with us. But 
this is not for the public and I will not discuss it much deeper.

But yes, Alaska Software's strategy is to provide a full, complete and 
consistent solution for its customers which integrate in Xbase++. So are 
WebHandler() and HttpEndpoint(). HtmlClient() is our latest feature and 
more to come.

This is true for SQL, Universal SQL, DataObjects, ... and all 
forthcoming from Alaska Software.

There is no cannibalizing. At least not willingly.

Side note: I checked your change LOG and i.e. you were introducing your 
xbWebSocket() in October 2015. We have it since 2013. Should I ask who 
is cannibalizing who? No, I don't. I also do not ask who's in "beta"!?

And all of the above requires to improve our compiler. And all customers 
are gaining from our efforts.

And finally, guess what: there are customers - and thank god there are 
many - who do want all from one hand, from one company. And these are 
happy with our feature set and they even have demand for more.
Which helps improving the compiler.
Which in turn helps being around.
Which helps giving you a home for your 3rd party product(s).

Have a nice day
Frank



On 29.03.2018 20:21, Boris Borzic wrote:
> Frank Grossheinrich wrote in
> news:368b45cb$7558fe88$35c254@news.alaska-software.com:
>
>> Finally, if you are willing completely to re-write your application to
>> a web application which entirely runs into a browser - as Boris
>> suggested - you could use HttpEndpoint() and a WebHandler() and you do
>> not need any 3rd party product. It's all Xbase++.
>
>
> Frank: I'm terribly sorry but I must ask. Is this the Alaska Software
> strategy now?
>
> Improving the core compiler is too difficult so you start cannibalizing
> your 3rd party technology "partners" for ideas and developing competing
> products. Kindly explain this to me, because I just don't get it!
>
> Your 3rd party "partners" are not stealing customers from you. Every
> single one, 100% of my customers is also an Xbase++ user and an Alaska
> Software customer. To make your product better, you need to
> support/encourage your "partners" not compete against them. Doing
> otherwise is a fool's strategy.
>
> Furthermore, Xb2.NET was released in 2002 - that's 16 years ago. During
> this time it has been continually enhanced and improved. It is an
> incredibly robust and stable library! It is a disservice to your users
> and customers to suggest that your new competing 'beta' product is
> somehow superior.
>
> We use Xb2.NET in our own DivertCode warehouse automation software where
> it runs 24/7 under extremely demanding conditions (using Xbase++
> 1.90.355). Not only is this a testament to how good Xb2.NET is, but is
> also a testament to how good the Xbase++ compiler is. That core compiler
> however is now quite old and very little has been done in Xbase++ 2.0 to
> improve it. This is one reason why we continue to use 1.90 in our own
> production environments (FYI, both SQLExpress + Xb2.NET support Xbase++
> 1.82 - 2.0).
>
> Nevertheless, I am supporting you with my annual subscription to Xbase++
> 2.0. Though to be quite honest, between SQLExpress and Xb2.NET there is
> little compelling reason for me to use Xbase++ 2.0 or any of the "new"
> stuff that has been added to it. I do hope that a small portion of my
> annual contribution will be well spent in enhancing the core compiler
> and expanding the user base.
>

Frank Grossheinrich wrote in news:208ce722$608d9c20$4d7ed5@news.alaska-
software.com:
> hmmmm, I would like to express my completely un-technically feeling that 
> I am not very happy with your attitude towards Xbase++ and Alaska 
> Software. I often think that you do not value a partnership with us.


I'm sorry you feel this way. However, I must say that nothing is further 
from the truth!!!

I have been an active Xbase++ supporter from day one (going back to 97/98 - 
please check the archives on this newsgroup). Few have advocated and 
contributed more to the success of Xbase++ (and Alaska Software) than 
myself. I even hosted Alaska Software (attended by Steffen & Claudia) at a 
small Xbase++ user conference in Toronto (2008) - organized and 100% paid 
for out of my own pocket - all in the effort to support You, Alaska 
Software and promote Xbase++. To be honest, I am insulted by your comment 
because what you are insinuating is FALSE! 

I would really like to know what I have done to make you 'feel' this way. 
Kindly forward to my private email any comments/posting that I may have 
made in the past which support your assertion. I look forward to discussing 
your concerns in private (email, skype, telephone).

Sincerely,
Boris Borzic

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

See your email.

On 06.04.2018 02:12, Boris Borzic wrote:
> Frank Grossheinrich wrote in news:208ce722$608d9c20$4d7ed5@news.alaska-
> software.com:
>> hmmmm, I would like to express my completely un-technically feeling that
>> I am not very happy with your attitude towards Xbase++ and Alaska
>> Software. I often think that you do not value a partnership with us.
>
>
> I'm sorry you feel this way. However, I must say that nothing is further
> from the truth!!!
>
> I have been an active Xbase++ supporter from day one (going back to 97/98 -
> please check the archives on this newsgroup). Few have advocated and
> contributed more to the success of Xbase++ (and Alaska Software) than
> myself. I even hosted Alaska Software (attended by Steffen & Claudia) at a
> small Xbase++ user conference in Toronto (2008) - organized and 100% paid
> for out of my own pocket - all in the effort to support You, Alaska
> Software and promote Xbase++. To be honest, I am insulted by your comment
> because what you are insinuating is FALSE!
>
> I would really like to know what I have done to make you 'feel' this way.
> Kindly forward to my private email any comments/posting that I may have
> made in the past which support your assertion. I look forward to discussing
> your concerns in private (email, skype, telephone).
>

i think like Boris that Alaska messes with all the new features instead of 
finally finishing all 26 Common Control.
i do not see what the new stuff in 2.x should bring me to advantage if it is 
so slow like PgDBE that you can not use it.
btw. Phil Ide already had a native PG interface in Year 2000, which is fast 
and working !

i agree with Boris Alaska should focus on what the core is: The Compiler! a 
64bit version is NEED !
and do not tell us the story again "it's just a switch" ... so why does 
Alaska not do that ?!

3PP Libs has always been the business of external people who have a clue 
about the matter.
it is also common that a 3PP user interfaces is provides API descriptions 
e.g. the DBE

you do survive through cooperation and quality does not honor quantity.
the quality is not correct if and only 50% is delivered like most XbPart 
where still controls such as Listview are missing.
also the XbParts which need MSCOMCTL.OCX should be finally available as 
native Control. those are the things with which one works normally.

for the problem with XbpHTMLviewer(), i can only say that it is based on IE 
and is (real) outdated,

Hi Frank,

I'll send you a note and an example program, I also believe it has something 
to do with "crapy" sites because testing and testing with more than 40 
webshop integrations i noticed the memory consume is less for several sites 
but still there is some.


Frank Grossheinrich wrote in message news:368b45cb$7558fe88
$35c254@news.alaska-software.com...
>Nico,
>
>please contact our Technical Support team.
>I had a very brief discussion with them while lunch  and they do not 
>think this is related to XbpHtmlViewer (which is an ActiveX control). So 
>maybe they can help here. At least we are interested in any momory 
>consuming issue!
>
>Finally, if you are willing completely to re-write your application to a 
>web application which entirely runs into a browser - as Boris suggested 
>- you could use HttpEndpoint() and a WebHandler() and you do not need 
>any 3rd party product. It's all Xbase++.
>
>Regards
>Frank
>
>On 27.03.2018 16:54, Nico Houben wrote:
>> We have several forms in our application using the XbpHtmlViewer. (xbase 
1.9
>> and 2.0)
>>
>> After a while using the application and opening and closing the
>> xbphtmlviewer (destroy object, etc)
>> we get random Not enough memory error's.
>>
>> If we don't use the control in our tests we don't see the memory usage of
>> the application growing and neither do we see the not enough memory 
error's.
>>
>> Memory isn't released by the webbrowser control. Some simple googling
>> "webbrowser memory leak" you find a lot of projects having the same issue.
>>
>> Has anybody found a good solution ?
>> Is there any suggestion for an alternative ?
>> Has somebody builded a wrapper around chromium/other browsers ?
>>
>> Kind regards,Nico
>>

Nico,

I checked back with my colleagues and they have no sample yet.
And I am still curious !

Regards, Frank

On 29.03.2018 21:05, Nico Houben wrote:
> Hi Frank,
>
> I'll send you a note and an example program, I also believe it has something
> to do with "crapy" sites because testing and testing with more than 40
> webshop integrations i noticed the memory consume is less for several sites
> but still there is some.
>
>
> Frank Grossheinrich wrote in message news:368b45cb$7558fe88
> $35c254@news.alaska-software.com...
>> Nico,
>>
>> please contact our Technical Support team.
>> I had a very brief discussion with them while lunch  and they do not
>> think this is related to XbpHtmlViewer (which is an ActiveX control). So
>> maybe they can help here. At least we are interested in any momory
>> consuming issue!
>>
>> Finally, if you are willing completely to re-write your application to a
>> web application which entirely runs into a browser - as Boris suggested
>> - you could use HttpEndpoint() and a WebHandler() and you do not need
>> any 3rd party product. It's all Xbase++.
>>
>> Regards
>> Frank
>>
>> On 27.03.2018 16:54, Nico Houben wrote:
>>> We have several forms in our application using the XbpHtmlViewer. (xbase
> 1.9
>>> and 2.0)
>>>
>>> After a while using the application and opening and closing the
>>> xbphtmlviewer (destroy object, etc)
>>> we get random Not enough memory error's.
>>>
>>> If we don't use the control in our tests we don't see the memory usage of
>>> the application growing and neither do we see the not enough memory
> error's.
>>>
>>> Memory isn't released by the webbrowser control. Some simple googling
>>> "webbrowser memory leak" you find a lot of projects having the same issue.
>>>
>>> Has anybody found a good solution ?
>>> Is there any suggestion for an alternative ?
>>> Has somebody builded a wrapper around chromium/other browsers ?
>>>
>>> Kind regards,Nico
>>>

I've found this one:

www.webkitx.com 

It's a chromium ActiveX component, and many sites are responding better in 
chromium and even much faster.
I'm still testing now, no memory consuming now.

On 3/27/2018 10:54 AM, Nico Houben wrote:
> We have several forms in our application using the XbpHtmlViewer. (xbase 1.9
> and 2.0)
>
> After a while using the application and opening and closing the
> xbphtmlviewer (destroy object, etc)
> we get random Not enough memory error's.
>
> If we don't use the control in our tests we don't see the memory usage of
> the application growing and neither do we see the not enough memory error's.
>
> Memory isn't released by the webbrowser control. Some simple googling
> "webbrowser memory leak" you find a lot of projects having the same issue.
>
> Has anybody found a good solution ?
> Is there any suggestion for an alternative ?
> Has somebody builded a wrapper around chromium/other browsers ?
>
> Kind regards,Nico
>


I've been doing more testing today, and I'm seeing some really weird 
issues when using the Xbase++ 2.0 xbpHtmlViewer under Windows 10.  If I 
bring up a web page, click around a bit, then exit out, I can longer 
launch a print job using List & Label 23, and I start getting "out of 
memory" errors.  I tried navigating to "about:blank" as suggested above, 
but that didn't seem to help. If I recompile my application with Xbase++ 
1.90.355, the xbpHtmlViewer object works fine.  I can print after I use 
it, and I don't see any out of memory errors.

I'm rewriting my code to use CreateObject(InternetExplorer.application) 
instead of xbpHtmlViewer objects, as I described in my previous post in 
this thread.  Hopefully that will solve my problems.

Also, FWIW, we use XB2.net and love it! 

If Nico's xbpHtmlViewer issues are resolved, someone please post the 
solution here in the newsgroup so the rest of us can benefit from the 
knowledge.  I would prefer to use xbpHtmlViewer if I could get it to 
work properly.

Thanks!

Chris Carmac

Chris Carmac <ccarmac@freedomsoft.info> wrote in news:7cd1d414$18955f5
$38d4bd@news.alaska-software.com:

> Also, FWIW, we use XB2.net and love it! 

Thank you for your kind words and support!

Best regards,
Boris Borzic

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

Hello,
sorry for jumping in, but for me the tools from Boris were always the
much better solutions. They are much more powerful, very stable (take a
look at the docs on his site) and he has a perfect support and very good
doucmentation. They are a perfect supplement to xBase++.  The same is
eXpress++ for me. Without this tools and the support for them I never
would have continued using xBase++. WAA and ODBCDBE have been never a
solution for me. And I am sure I am not alone with this opinion.  Alaska
never would be able to substitute this tools. I think Alaska should keep
this always in mind and try to help them to support xBasee++ also in the
future and not to to be a competitor.
So I hope for peace between Alaska and Boris 


Am 31.03.2018 um 18:22 schrieb Boris Borzic:
> Chris Carmac <ccarmac@freedomsoft.info> wrote in news:7cd1d414$18955f5
> $38d4bd@news.alaska-software.com:
>
>> Also, FWIW, we use XB2.net and love it! 
>
> Thank you for your kind words and support!
>


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Rudolf Reinthaler wrote in
news:135a9d45$7b218ba3$6c3d6@news.alaska-software.com: 

Rudolf,
you are not alone in your opinion...
My feelings exactly..


> Hello,
> sorry for jumping in, but for me the tools from Boris were always the
> much better solutions. They are much more powerful, very stable (take
> a look at the docs on his site) and he has a perfect support and very
> good doucmentation. They are a perfect supplement to xBase++.  The
> same is eXpress++ for me. Without this tools and the support for them
> I never would have continued using xBase++. WAA and ODBCDBE have been
> never a solution for me. And I am sure I am not alone with this
> opinion.  Alaska never would be able to substitute this tools. I think
> Alaska should keep this always in mind and try to help them to support
> xBasee++ also in the future and not to to be a competitor.
> So I hope for peace between Alaska and Boris 
> 
> 
> Am 31.03.2018 um 18:22 schrieb Boris Borzic:
>> Chris Carmac <ccarmac@freedomsoft.info> wrote in
>> news:7cd1d414$18955f5 $38d4bd@news.alaska-software.com:
>>
>>> Also, FWIW, we use XB2.net and love it! 
>>
>> Thank you for your kind words and support!
>>
> 
> 
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
> 
>

Hello Brian, thank you !

Am 07.04.2018 um 15:25 schrieb Brian Wolfsohn:
> Rudolf Reinthaler wrote in
> news:135a9d45$7b218ba3$6c3d6@news.alaska-software.com:
> 
> Rudolf,
> you are not alone in your opinion...
> My feelings exactly..
> 
> 
>> Hello,
>> sorry for jumping in, but for me the tools from Boris were always the
>> much better solutions. They are much more powerful, very stable (take
>> a look at the docs on his site) and he has a perfect support and very
>> good doucmentation. They are a perfect supplement to xBase++.  The
>> same is eXpress++ for me. Without this tools and the support for them
>> I never would have continued using xBase++. WAA and ODBCDBE have been
>> never a solution for me. And I am sure I am not alone with this
>> opinion.  Alaska never would be able to substitute this tools. I think
>> Alaska should keep this always in mind and try to help them to support
>> xBasee++ also in the future and not to to be a competitor.
>> So I hope for peace between Alaska and Boris 
>>
>>
>> Am 31.03.2018 um 18:22 schrieb Boris Borzic:
>>> Chris Carmac <ccarmac@freedomsoft.info> wrote in
>>> news:7cd1d414$18955f5 $38d4bd@news.alaska-software.com:
>>>
>>>> Also, FWIW, we use XB2.net and love it! 
>>>
>>> Thank you for your kind words and support!
>>>
>>
>>
>> ---
>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprÃŒft.
>> https://www.avast.com/antivirus
>>
>>
> 


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Rudolf Reinthaler wrote in news:135a9d45$7b218ba3$6c3d6@news.alaska-
software.com:

> sorry for jumping in, but for me the tools from Boris were always the
> much better solutions. They are much more powerful, very stable (take a
> look at the docs on his site) and he has a perfect support and very good
> doucmentation. They are a perfect supplement to xBase++.  The same is
> eXpress++ for me. Without this tools and the support for them I never
> would have continued using xBase++. WAA and ODBCDBE have been never a
> solution for me. And I am sure I am not alone with this opinion.  Alaska
> never would be able to substitute this tools. I think Alaska should keep
> this always in mind and try to help them to support xBasee++ also in the
> future and not to to be a competitor.

Thank you Rodolf. 

A successful product needs a strong 3P community. This was true 30 years 
ago for Clipper and I'm pretty sure it applies today. It's safe to say that 
Alaska Software would have far fewer customers today were it not for 3'rd 
party products like eXpress++, TopDown, XClass++ and my own contributions 
SQLExpress & Xb2.NET. 

However the 3P can only do so much. We can't for example turn Xbase++ into 
a 64-bit compiler and we can't make your Xbase++ executable run on multiple 
cores/CPUs. These are just some of the HARD problems that only Alaska 
Software can solve. As an Alaska customer myself, I wish that more effort 
was expended on these HARD problems instead of developing solutions to 
problems that have been solved long ago and which, by the way, end up 
fragmenting the small Xbase++ community.

Best regards,
Boris Borzic

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

Boris Borzic wrote in news:XnsA8BF5A96AD3DASQLExpress@87.106.143.233:

+1
+1
+1

> A successful product needs a strong 3P community. This was true 30
> years ago for Clipper and I'm pretty sure it applies today. It's safe
> to say that Alaska Software would have far fewer customers today were
> it not for 3'rd party products like eXpress++, TopDown, XClass++ and
> my own contributions SQLExpress & Xb2.NET. 
> 
> However the 3P can only do so much. We can't for example turn Xbase++
> into a 64-bit compiler and we can't make your Xbase++ executable run
> on multiple cores/CPUs. These are just some of the HARD problems that
> only Alaska Software can solve. As an Alaska customer myself, I wish
> that more effort was expended on these HARD problems instead of
> developing solutions to problems that have been solved long ago and
> which, by the way, end up fragmenting the small Xbase++ community.
>

Rudolph,

first of all:
LOCAL cProperProductName := Upper( „X“ ) + Lower( „base++“ )
? cProperProductName

Second: peace for all mankind.

Third: no one ever said that Boris' 3rd party products are bad. All 3rd 
party products which help our customers are GREAT per se! And Boris has 
a great community. At least you guys are very loyal.

But there are - and this is my point - also many customers using 
more/much beside our compiler. And this community is still much 
increasing and demanding. And all of you should have a look to all 
directions. At least a look! Stick with whatever you like to stick, but 
keep an open eye to every solution.

Otherwise this discussion is getting more and more a "what editor is the 
best" discussion. And this discussion has no winner.

Get back to second  (see above)

Regards
Frank


On 06.04.2018 09:53, Rudolf Reinthaler wrote:
> Hello,
> sorry for jumping in, but for me the tools from Boris were always the
> much better solutions. They are much more powerful, very stable (take a
> look at the docs on his site) and he has a perfect support and very good
> doucmentation. They are a perfect supplement to xBase++.  The same is
> eXpress++ for me. Without this tools and the support for them I never
> would have continued using xBase++. WAA and ODBCDBE have been never a
> solution for me. And I am sure I am not alone with this opinion.  Alaska
> never would be able to substitute this tools. I think Alaska should keep
> this always in mind and try to help them to support xBasee++ also in the
> future and not to to be a competitor.
> So I hope for peace between Alaska and Boris 
>
>
> Am 31.03.2018 um 18:22 schrieb Boris Borzic:
>> Chris Carmac <ccarmac@freedomsoft.info> wrote in news:7cd1d414$18955f5
>> $38d4bd@news.alaska-software.com:
>>
>>> Also, FWIW, we use XB2.net and love it! 
>>
>> Thank you for your kind words and support!
>>
>
>
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
>