I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
Crystal Reports.  I've found that certain ActiveXs that work well as small, 
stand-alone application, would crash a large one.  A simple ActiveX that 
only utilizes a few methods and variables of a COM-Object can be 
incorporated into a large application, but a bit more complex ActiveX can 
only run well as a small, stand-alone, dedicated application (It runs well 
as RunShell).  Incorporating the same procedure into a large application 
would crash it.  Years ago, I had similar problem with JazzAge, and the 
solution then was to RunShell() the ActivXs, but I was hoping that the 
release of SL1 would eliminate the need for multiple executables.

Is there a better work-around this problem?

Thank you, Alaska.

-Itai

Hallo Itai,

Can you please contact Alaska Software Technical Support regarding
this issue.

The information you give with your posting are not very specific.
I would like to know what the ActiveX component is, how you differ
from "small application", "large application", "few methods" and
"bit more complex". Furthermore, what are the errors you are
encountering?

IBA schrieb:
> I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
> Crystal Reports.  I've found that certain ActiveXs that work well as small, 
> stand-alone application, would crash a large one.  A simple ActiveX that 
> only utilizes a few methods and variables of a COM-Object can be 
> incorporated into a large application, but a bit more complex ActiveX can 
> only run well as a small, stand-alone, dedicated application (It runs well 
> as RunShell).  Incorporating the same procedure into a large application 
> would crash it.  Years ago, I had similar problem with JazzAge, and the 
> solution then was to RunShell() the ActivXs, but I was hoping that the 
> release of SL1 would eliminate the need for multiple executables.
> 
> Is there a better work-around this problem?
> 
> Thank you, Alaska.
> 
> -Itai
> 
> 

With my best regards,

Andreas Herdt

   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
--------------------------------------------------------------------

Here is the info:

1. The current application is "CrystalRuntime.Application.11" (A few years 
ago I had similar situations with Word).

2. A small application is less then 400 lines of code.

3. A large application is more then 200,000 lines of code.

4. A "few methods" mean open, display and close the aciveX object.

5. A "bit more complex" means attempts to open additional tabs, 
expend/collapse a tree, changing zoom and similar methods.

6. The crashes resulted in computer freeze and no refresh/redraw of any 
graphic (including non-xbase windows)



I hope it helps.

-Itai



<Andreas Herdt> wrote in message 
news:7aa25684$3db2e847$5d383@news.alaska-software.com...
> Hallo Itai,
>
> Can you please contact Alaska Software Technical Support regarding
> this issue.
>
> The information you give with your posting are not very specific.
> I would like to know what the ActiveX component is, how you differ
> from "small application", "large application", "few methods" and
> "bit more complex". Furthermore, what are the errors you are
> encountering?
>
> IBA schrieb:
>> I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
>> Crystal Reports.  I've found that certain ActiveXs that work well as 
>> small, stand-alone application, would crash a large one.  A simple 
>> ActiveX that only utilizes a few methods and variables of a COM-Object 
>> can be incorporated into a large application, but a bit more complex 
>> ActiveX can only run well as a small, stand-alone, dedicated application 
>> (It runs well as RunShell).  Incorporating the same procedure into a 
>> large application would crash it.  Years ago, I had similar problem with 
>> JazzAge, and the solution then was to RunShell() the ActivXs, but I was 
>> hoping that the release of SL1 would eliminate the need for multiple 
>> executables.
>>
>> Is there a better work-around this problem?
>>
>> Thank you, Alaska.
>>
>> -Itai
>>
>>
>
> With my best regards,
>
> Andreas Herdt
>
> -- 
>   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
> --------------------------------------------------------------------

Itai,

I think Andreas wants you to send the information to
support@alaska-software.com.

  >don<

On Sun, 6 Sep 2009 02:05:28 -0700, IBA wrote:

> Here is the info:
> 
> 1. The current application is "CrystalRuntime.Application.11" (A few
years 
> ago I had similar situations with Word).
> 
> 2. A small application is less then 400 lines of code.
> 
> 3. A large application is more then 200,000 lines of code.
> 
> 4. A "few methods" mean open, display and close the aciveX object.
> 
> 5. A "bit more complex" means attempts to open additional tabs, 
> expend/collapse a tree, changing zoom and similar methods.
> 
> 6. The crashes resulted in computer freeze and no refresh/redraw of any 
> graphic (including non-xbase windows)
> 
> 
> 
> I hope it helps.
> 
> -Itai
> 
> 
> 
> <Andreas Herdt> wrote in message 
> news:7aa25684$3db2e847$5d383@news.alaska-software.com...
> > Hallo Itai,
> >
> > Can you please contact Alaska Software Technical Support regarding
> > this issue.
> >
> > The information you give with your posting are not very specific.
> > I would like to know what the ActiveX component is, how you differ
> > from "small application", "large application", "few methods" and
> > "bit more complex". Furthermore, what are the errors you are
> > encountering?
> >
> > IBA schrieb:
> >> I am utilizing the ActiveX to connect with Word, Excel, IE and
recently 
> >> Crystal Reports.  I've found that certain ActiveXs that work well as 
> >> small, stand-alone application, would crash a large one.  A simple 
> >> ActiveX that only utilizes a few methods and variables of a COM-Object 
> >> can be incorporated into a large application, but a bit more complex 
> >> ActiveX can only run well as a small, stand-alone, dedicated
application 
> >> (It runs well as RunShell).  Incorporating the same procedure into a 
> >> large application would crash it.  Years ago, I had similar problem
with 
> >> JazzAge, and the solution then was to RunShell() the ActivXs, but I
was 
> >> hoping that the release of SL1 would eliminate the need for multiple 
> >> executables.
> >>
> >> Is there a better work-around this problem?
> >>
> >> Thank you, Alaska.
> >>
> >> -Itai
> >>
> >>
> >
> > With my best regards,
> >
> > Andreas Herdt
> >
> > -- 
> >   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
> > --------------------------------------------------------------------

Hi IBA,

I have recently had a similar experience where I run a retail airtime 
activex control.
The methods that would hang the system all had to deal with string fields.
For example the activex method called for a string field of 32 
bytes....well that blew it up so i took a wild guess and gave it 40 bytes 
and that took care of that problem.
I had another instance where the same activex control needs to pass back a 
variable string. The spec required  a maximum of 250 bytes so I gave it a 
buffer string
of 250 bytes and that blew up so i gave it increments of ten until it 
worked. And the funny thing is that a lot of times it did not blow up in the 
activex control that caused the problem,  it would blow somewhere else in 
the program that used a totally different object that was not even an 
activex.  But I also found that giving it to big of a string field would 
also make it blow/freeze the entire computer.....Note that all of this could 
be due to the activex control being speced/written badly.

Kind regards,
Nestor


"IBA" <iba@adelphia.net> wrote in message 
news:52b31d96$788183bd$677fc@news.alaska-software.com...
> Here is the info:
>
> 1. The current application is "CrystalRuntime.Application.11" (A few years 
> ago I had similar situations with Word).
>
> 2. A small application is less then 400 lines of code.
>
> 3. A large application is more then 200,000 lines of code.
>
> 4. A "few methods" mean open, display and close the aciveX object.
>
> 5. A "bit more complex" means attempts to open additional tabs, 
> expend/collapse a tree, changing zoom and similar methods.
>
> 6. The crashes resulted in computer freeze and no refresh/redraw of any 
> graphic (including non-xbase windows)
>
>
>
> I hope it helps.
>
> -Itai
>
>
>
> <Andreas Herdt> wrote in message 
> news:7aa25684$3db2e847$5d383@news.alaska-software.com...
>> Hallo Itai,
>>
>> Can you please contact Alaska Software Technical Support regarding
>> this issue.
>>
>> The information you give with your posting are not very specific.
>> I would like to know what the ActiveX component is, how you differ
>> from "small application", "large application", "few methods" and
>> "bit more complex". Furthermore, what are the errors you are
>> encountering?
>>
>> IBA schrieb:
>>> I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
>>> Crystal Reports.  I've found that certain ActiveXs that work well as 
>>> small, stand-alone application, would crash a large one.  A simple 
>>> ActiveX that only utilizes a few methods and variables of a COM-Object 
>>> can be incorporated into a large application, but a bit more complex 
>>> ActiveX can only run well as a small, stand-alone, dedicated application 
>>> (It runs well as RunShell).  Incorporating the same procedure into a 
>>> large application would crash it.  Years ago, I had similar problem with 
>>> JazzAge, and the solution then was to RunShell() the ActivXs, but I was 
>>> hoping that the release of SL1 would eliminate the need for multiple 
>>> executables.
>>>
>>> Is there a better work-around this problem?
>>>
>>> Thank you, Alaska.
>>>
>>> -Itai
>>>
>>>
>>
>> With my best regards,
>>
>> Andreas Herdt
>>
>> -- 
>>   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
>> -------------------------------------------------------------------- 
>
>

Just one more thing about the error I would also sometimes get before 
adjusting the string sizes:

Message sent to activex provider:
     Hi Riaan,

     Attached find the log file you requested.

     To summarise: We get a Operating system error: 61706 ...insufficient 
memory to perform operation.
                             operation: li_commit_item

     This happens after the third iteration of contructing a line item for a 
customer taking buying 3 airtime vouchers...
     or after the third customer buying an airtime voucher.


    Kind regards,
    Nestor





<Nestor G. Torres> wrote in message 
news:6137191d$18b35cd9$6a752@news.alaska-software.com...
> Hi IBA,
>
> I have recently had a similar experience where I run a retail airtime 
> activex control.
> The methods that would hang the system all had to deal with string fields.
> For example the activex method called for a string field of 32 
> bytes....well that blew it up so i took a wild guess and gave it 40 bytes 
> and that took care of that problem.
> I had another instance where the same activex control needs to pass back a 
> variable string. The spec required  a maximum of 250 bytes so I gave it a 
> buffer string
> of 250 bytes and that blew up so i gave it increments of ten until it 
> worked. And the funny thing is that a lot of times it did not blow up in 
> the activex control that caused the problem,  it would blow somewhere else 
> in the program that used a totally different object that was not even an 
> activex.  But I also found that giving it to big of a string field would 
> also make it blow/freeze the entire computer.....Note that all of this 
> could be due to the activex control being speced/written badly.
>
> Kind regards,
> Nestor
>
>
> "IBA" <iba@adelphia.net> wrote in message 
> news:52b31d96$788183bd$677fc@news.alaska-software.com...
>> Here is the info:
>>
>> 1. The current application is "CrystalRuntime.Application.11" (A few 
>> years ago I had similar situations with Word).
>>
>> 2. A small application is less then 400 lines of code.
>>
>> 3. A large application is more then 200,000 lines of code.
>>
>> 4. A "few methods" mean open, display and close the aciveX object.
>>
>> 5. A "bit more complex" means attempts to open additional tabs, 
>> expend/collapse a tree, changing zoom and similar methods.
>>
>> 6. The crashes resulted in computer freeze and no refresh/redraw of any 
>> graphic (including non-xbase windows)
>>
>>
>>
>> I hope it helps.
>>
>> -Itai
>>
>>
>>
>> <Andreas Herdt> wrote in message 
>> news:7aa25684$3db2e847$5d383@news.alaska-software.com...
>>> Hallo Itai,
>>>
>>> Can you please contact Alaska Software Technical Support regarding
>>> this issue.
>>>
>>> The information you give with your posting are not very specific.
>>> I would like to know what the ActiveX component is, how you differ
>>> from "small application", "large application", "few methods" and
>>> "bit more complex". Furthermore, what are the errors you are
>>> encountering?
>>>
>>> IBA schrieb:
>>>> I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
>>>> Crystal Reports.  I've found that certain ActiveXs that work well as 
>>>> small, stand-alone application, would crash a large one.  A simple 
>>>> ActiveX that only utilizes a few methods and variables of a COM-Object 
>>>> can be incorporated into a large application, but a bit more complex 
>>>> ActiveX can only run well as a small, stand-alone, dedicated 
>>>> application (It runs well as RunShell).  Incorporating the same 
>>>> procedure into a large application would crash it.  Years ago, I had 
>>>> similar problem with JazzAge, and the solution then was to RunShell() 
>>>> the ActivXs, but I was hoping that the release of SL1 would eliminate 
>>>> the need for multiple executables.
>>>>
>>>> Is there a better work-around this problem?
>>>>
>>>> Thank you, Alaska.
>>>>
>>>> -Itai
>>>>
>>>>
>>>
>>> With my best regards,
>>>
>>> Andreas Herdt
>>>
>>> -- 
>>>   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
>>> -------------------------------------------------------------------- 
>>
>>
>
>

Just one more thing....The activex method that caused the error had many 
parameters and in between these parameters were the string field requested 
or being sent back.

Kind regards,
Nestor

<Nestor G. Torres> wrote in message 
news:603a0140$1ed77a2e$85956@news.alaska-software.com...
> Just one more thing about the error I would also sometimes get before 
> adjusting the string sizes:
>
> Message sent to activex provider:
>     Hi Riaan,
>
>     Attached find the log file you requested.
>
>     To summarise: We get a Operating system error: 61706 ...insufficient 
> memory to perform operation.
>                             operation: li_commit_item
>
>     This happens after the third iteration of contructing a line item for 
> a customer taking buying 3 airtime vouchers...
>     or after the third customer buying an airtime voucher.
>
>
>    Kind regards,
>    Nestor
>
>
>
>
>
> <Nestor G. Torres> wrote in message 
> news:6137191d$18b35cd9$6a752@news.alaska-software.com...
>> Hi IBA,
>>
>> I have recently had a similar experience where I run a retail airtime 
>> activex control.
>> The methods that would hang the system all had to deal with string 
>> fields.
>> For example the activex method called for a string field of 32 
>> bytes....well that blew it up so i took a wild guess and gave it 40 bytes 
>> and that took care of that problem.
>> I had another instance where the same activex control needs to pass back 
>> a variable string. The spec required  a maximum of 250 bytes so I gave it 
>> a buffer string
>> of 250 bytes and that blew up so i gave it increments of ten until it 
>> worked. And the funny thing is that a lot of times it did not blow up in 
>> the activex control that caused the problem,  it would blow somewhere 
>> else in the program that used a totally different object that was not 
>> even an activex.  But I also found that giving it to big of a string 
>> field would also make it blow/freeze the entire computer.....Note that 
>> all of this could be due to the activex control being speced/written 
>> badly.
>>
>> Kind regards,
>> Nestor
>>
>>
>> "IBA" <iba@adelphia.net> wrote in message 
>> news:52b31d96$788183bd$677fc@news.alaska-software.com...
>>> Here is the info:
>>>
>>> 1. The current application is "CrystalRuntime.Application.11" (A few 
>>> years ago I had similar situations with Word).
>>>
>>> 2. A small application is less then 400 lines of code.
>>>
>>> 3. A large application is more then 200,000 lines of code.
>>>
>>> 4. A "few methods" mean open, display and close the aciveX object.
>>>
>>> 5. A "bit more complex" means attempts to open additional tabs, 
>>> expend/collapse a tree, changing zoom and similar methods.
>>>
>>> 6. The crashes resulted in computer freeze and no refresh/redraw of any 
>>> graphic (including non-xbase windows)
>>>
>>>
>>>
>>> I hope it helps.
>>>
>>> -Itai
>>>
>>>
>>>
>>> <Andreas Herdt> wrote in message 
>>> news:7aa25684$3db2e847$5d383@news.alaska-software.com...
>>>> Hallo Itai,
>>>>
>>>> Can you please contact Alaska Software Technical Support regarding
>>>> this issue.
>>>>
>>>> The information you give with your posting are not very specific.
>>>> I would like to know what the ActiveX component is, how you differ
>>>> from "small application", "large application", "few methods" and
>>>> "bit more complex". Furthermore, what are the errors you are
>>>> encountering?
>>>>
>>>> IBA schrieb:
>>>>> I am utilizing the ActiveX to connect with Word, Excel, IE and 
>>>>> recently Crystal Reports.  I've found that certain ActiveXs that work 
>>>>> well as small, stand-alone application, would crash a large one.  A 
>>>>> simple ActiveX that only utilizes a few methods and variables of a 
>>>>> COM-Object can be incorporated into a large application, but a bit 
>>>>> more complex ActiveX can only run well as a small, stand-alone, 
>>>>> dedicated application (It runs well as RunShell).  Incorporating the 
>>>>> same procedure into a large application would crash it.  Years ago, I 
>>>>> had similar problem with JazzAge, and the solution then was to 
>>>>> RunShell() the ActivXs, but I was hoping that the release of SL1 would 
>>>>> eliminate the need for multiple executables.
>>>>>
>>>>> Is there a better work-around this problem?
>>>>>
>>>>> Thank you, Alaska.
>>>>>
>>>>> -Itai
>>>>>
>>>>>
>>>>
>>>> With my best regards,
>>>>
>>>> Andreas Herdt
>>>>
>>>> -- 
>>>>   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
>>>> -------------------------------------------------------------------- 
>>>
>>>
>>
>>
>
>

Hi

I think I may have spoken to soon about the work around that seemed to work 
for me.

Changing string field sizes for the activex parameters only seems to work to 
a point.

I have now been testing my application with a serial thermal printer that 
works very well
without using my additional activex controls. Once I start making use of the 
activex controls,
for some business functions, the serial printer works a few times and then 
stops working.

I use topdown to create my printer object for a generic text printer. Then I 
use the activex control
to do some business functions followed by printing to the generic text 
printer print object. I end the
document followed by destroying the print object and ending the thread 
...all works ok...but creating
a new thread followed by the same process will eventually (plus minus three 
time) make the new
print object stop working (no printing is possible) but does not hang 
system. I then go to the
Windows faxes and printer setting and open the generic text printer and 
print a test page with no problem.
Exiting the application and re-entering then the printer works again.

Can Alaska please help....Since in my small mind i believe that the activex 
automation engine is
bleeding inside...maybe thats not the right way of describing it.

Kind regards,
Nestor

"IBA" <iba@adelphia.net> wrote in message 
news:1260f0bd$32e1765a$5d2f5@news.alaska-software.com...
>I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
>Crystal Reports.  I've found that certain ActiveXs that work well as small, 
>stand-alone application, would crash a large one.  A simple ActiveX that 
>only utilizes a few methods and variables of a COM-Object can be 
>incorporated into a large application, but a bit more complex ActiveX can 
>only run well as a small, stand-alone, dedicated application (It runs well 
>as RunShell).  Incorporating the same procedure into a large application 
>would crash it.  Years ago, I had similar problem with JazzAge, and the 
>solution then was to RunShell() the ActivXs, but I was hoping that the 
>release of SL1 would eliminate the need for multiple executables.
>
> Is there a better work-around this problem?
>
> Thank you, Alaska.
>
> -Itai
>
>

hi,

i can not say what your activeX does, but most of my activeX do work with
Xbase++ v1.9x

SL1 v1.9.355 activeX "seems" me slower than v1.9.331+hotfix, but IMHO it
is more stable.
i "think" it is the EVM Manager who does better "sync" Xbase++ with activeX
... but "sync" need time

i also use different activeX within one big Application (WMP, Codejock +
Skinframework, L&L) without those "big" Problems.
i do agree that those activeX does not make much "communication"
from/to Xbase++ so they do not need much "sync".

i read about "String limitation" and "many" Parameter so there might be a
Problem with Xbase++ activeX.

i "think" String for activeX is limited to < 255.
this happend if i pass a "long" String to Excel :Range (&cString) ... or
is a "&" (macro) limted to < 255 ?

"many" Parameter "meen" much work ... work need time ...
"small" Application "meen" less Code ...  need not so much time ...

Question :
does your activeX need much "communication" time ?
are all your Parameter Type "C" ?

so i would try :

a.) other PC and other OS()
b.) "split" your Application and run, if possible, a external EXE

ad b.) yes i did "split" some activeX Code (Mappoint) into a
external EXE while it need to much CPU % and time.

... and depending on your Source Code ... did you try it with a "other"
Compiler ?

greetings by OHR
Jimmy

Hi Jimmy,

I am going to get ready to test on another computer ...but that is going to 
take me a bit of time to setup....
But I did not know that there were other compilers that would compile xbase 
code.....Can you let
me know where I can get hold of other compilers and linkers ....I would like 
to try that if possible.

I will need to think as to how to split my code if possible.....

Kind Regards
Nestor

"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
news:9df3764$41fc7f83$6f93@news.alaska-software.com...
> hi,
>
> i can not say what your activeX does, but most of my activeX do work with
> Xbase++ v1.9x
>
> SL1 v1.9.355 activeX "seems" me slower than v1.9.331+hotfix, but IMHO it
> is more stable.
> i "think" it is the EVM Manager who does better "sync" Xbase++ with 
> activeX
> ... but "sync" need time
>
> i also use different activeX within one big Application (WMP, Codejock +
> Skinframework, L&L) without those "big" Problems.
> i do agree that those activeX does not make much "communication"
> from/to Xbase++ so they do not need much "sync".
>
> i read about "String limitation" and "many" Parameter so there might be a
> Problem with Xbase++ activeX.
>
> i "think" String for activeX is limited to < 255.
> this happend if i pass a "long" String to Excel :Range (&cString) ... or
> is a "&" (macro) limted to < 255 ?
>
> "many" Parameter "meen" much work ... work need time ...
> "small" Application "meen" less Code ...  need not so much time ...
>
> Question :
> does your activeX need much "communication" time ?
> are all your Parameter Type "C" ?
>
> so i would try :
>
> a.) other PC and other OS()
> b.) "split" your Application and run, if possible, a external EXE
>
> ad b.) yes i did "split" some activeX Code (Mappoint) into a
> external EXE while it need to much CPU % and time.
>
> ... and depending on your Source Code ... did you try it with a "other"
> Compiler ?
>
> greetings by OHR
> Jimmy
>

I think he is talking about using a different language to see if the
problem may be with the ActiveX control. Just because it is a activeX
control does not mean that it is any good.

Are you destroying the activeX object before quiting the thread??

Jim

Nestor G. Torres wrote:
> Hi Jimmy,
> 
> I am going to get ready to test on another computer ...but that is going to 
> take me a bit of time to setup....
> But I did not know that there were other compilers that would compile xbase 
> code.....Can you let
> me know where I can get hold of other compilers and linkers ....I would like 
> to try that if possible.
> 
> I will need to think as to how to split my code if possible.....
> 
> Kind Regards
> Nestor
> 
> "AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
> news:9df3764$41fc7f83$6f93@news.alaska-software.com...
>> hi,
>>
>> i can not say what your activeX does, but most of my activeX do work with
>> Xbase++ v1.9x
>>
>> SL1 v1.9.355 activeX "seem´s" me slower than v1.9.331+hotfix, but IMHO it
>> is more stable.
>> i "think" it is the EVM Manager who does better "sync" Xbase++ with 
>> activeX
>> ... but "sync" need time
>>
>> i also use different activeX within one big Application (WMP, Codejock +
>> Skinframework, L&L) without those "big" Problems.
>> i do agree that those activeX does not make much "communication"
>> from/to Xbase++ so they do not need much "sync".
>>
>> i read about "String limitation" and "many" Parameter so there might be a
>> Problem with Xbase++ activeX.
>>
>> i "think" String for activeX is limited to < 255.
>> this happend if i pass a "long" String to Excel :Range (&cString) ... or
>> is a "&" (macro) limted to < 255 ?
>>
>> "many" Parameter "meen" much work ... work need time ...
>> "small" Application "meen" less Code ...  need not so much time ...
>>
>> Question :
>> does your activeX need much "communication" time ?
>> are all your Parameter Type "C" ?
>>
>> so i would try :
>>
>> a.) other PC and other OS()
>> b.) "split" your Application and run, if possible, a external EXE
>>
>> ad b.) yes i did "split" some activeX Code (Mappoint) into a
>> external EXE while it need to much CPU % and time.
>>
>> ... and depending on your Source Code ... did you try it with a "other"
>> Compiler ?
>>
>> greetings by OHR
>> Jimmy
>>
> 
>

Absolutley....The activex control is being used by many different retail 
developers.not in our xbase language......

my system doesn't freeze or blow up....it just stops working the com port 
printer...it's like it is working but nothing comes out..

Kind regards,
Nestor

"James Loughner" <jwrl@suddenlink.net> wrote in message 
news:34faa88a$43d58827$681e@news.alaska-software.com...
>I think he is talking about using a different language to see if the
> problem may be with the ActiveX control. Just because it is a activeX
> control does not mean that it is any good.
>
> Are you destroying the activeX object before quiting the thread??
>
> Jim
>
> Nestor G. Torres wrote:
>> Hi Jimmy,
>>
>> I am going to get ready to test on another computer ...but that is going 
>> to
>> take me a bit of time to setup....
>> But I did not know that there were other compilers that would compile 
>> xbase
>> code.....Can you let
>> me know where I can get hold of other compilers and linkers ....I would 
>> like
>> to try that if possible.
>>
>> I will need to think as to how to split my code if possible.....
>>
>> Kind Regards
>> Nestor
>>
>> "AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message
>> news:9df3764$41fc7f83$6f93@news.alaska-software.com...
>>> hi,
>>>
>>> i can not say what your activeX does, but most of my activeX do work 
>>> with
>>> Xbase++ v1.9x
>>>
>>> SL1 v1.9.355 activeX "seems" me slower than v1.9.331+hotfix, but IMHO 
>>> it
>>> is more stable.
>>> i "think" it is the EVM Manager who does better "sync" Xbase++ with
>>> activeX
>>> ... but "sync" need time
>>>
>>> i also use different activeX within one big Application (WMP, Codejock +
>>> Skinframework, L&L) without those "big" Problems.
>>> i do agree that those activeX does not make much "communication"
>>> from/to Xbase++ so they do not need much "sync".
>>>
>>> i read about "String limitation" and "many" Parameter so there might be 
>>> a
>>> Problem with Xbase++ activeX.
>>>
>>> i "think" String for activeX is limited to < 255.
>>> this happend if i pass a "long" String to Excel :Range (&cString) ... or
>>> is a "&" (macro) limted to < 255 ?
>>>
>>> "many" Parameter "meen" much work ... work need time ...
>>> "small" Application "meen" less Code ...  need not so much time ...
>>>
>>> Question :
>>> does your activeX need much "communication" time ?
>>> are all your Parameter Type "C" ?
>>>
>>> so i would try :
>>>
>>> a.) other PC and other OS()
>>> b.) "split" your Application and run, if possible, a external EXE
>>>
>>> ad b.) yes i did "split" some activeX Code (Mappoint) into a
>>> external EXE while it need to much CPU % and time.
>>>
>>> ... and depending on your Source Code ... did you try it with a "other"
>>> Compiler ?
>>>
>>> greetings by OHR
>>> Jimmy
>>>
>>
>>

Hi Itai,

After much batteling I have managed today to get my nomad activex calls to 
become stable. I'm not sure who to blame.
My supplier of the activex in question spec'd field Var1 should be a string 
of 32 bytes... var2 string 32 ...var3 string 128.
And that thes strings should be passed by reference@...

Calling the activex with those parameters made my serial printer not work 
after a while or with different sizes to run out of memory or freeze.

After much adjusting and scratching my head i got to a setting of var1 str 
38....  var2 str 38...var3 str 400...then it worked.
For example I was sending them a string by reference of 128 spaces and the 
method would return 400 to my buffer string of 128
overwriting what i believe was the program executable code in memory.

Now I believe these problems could have be resolved with the automation 
engine from alaska....I'm of the opinion if Alaska
can handle this type problem in the automation engine, that it would save on 
a lot of support call problems and time.

By the way thanks for your reply. I will also post this where we are having 
a dialogue on this issue.

Kind regards,
Nestor

"IBA" <iba@adelphia.net> wrote in message 
news:1260f0bd$32e1765a$5d2f5@news.alaska-software.com...
>I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
>Crystal Reports.  I've found that certain ActiveXs that work well as small, 
>stand-alone application, would crash a large one.  A simple ActiveX that 
>only utilizes a few methods and variables of a COM-Object can be 
>incorporated into a large application, but a bit more complex ActiveX can 
>only run well as a small, stand-alone, dedicated application (It runs well 
>as RunShell).  Incorporating the same procedure into a large application 
>would crash it.  Years ago, I had similar problem with JazzAge, and the 
>solution then was to RunShell() the ActivXs, but I was hoping that the 
>release of SL1 would eliminate the need for multiple executables.
>
> Is there a better work-around this problem?
>
> Thank you, Alaska.
>
> -Itai
>
>

I'd say the problem is with the code that is doc'ed to return 128 but
actually returns 400 causing a buffer overflow. When you pass a
reference you are actually passing a memory address. The called routine
then writes the return val at that address. There is nothing the calling
routine can do to stop this since by the time the caller gets control
back the damage has been done.

Jim


Nestor G. Torres wrote:
> Hi Itai,
> 
> After much batteling I have managed today to get my nomad activex calls to 
> become stable. I'm not sure who to blame.
> My supplier of the activex in question spec'd field Var1 should be a string 
> of 32 bytes... var2 string 32 ...var3 string 128.
> And that thes strings should be passed by reference@...
> 
> Calling the activex with those parameters made my serial printer not work 
> after a while or with different sizes to run out of memory or freeze.
> 
> After much adjusting and scratching my head i got to a setting of var1 str 
> 38....  var2 str 38...var3 str 400...then it worked.
> For example I was sending them a string by reference of 128 spaces and the 
> method would return 400 to my buffer string of 128
> overwriting what i believe was the program executable code in memory.
> 
> Now I believe these problems could have be resolved with the automation 
> engine from alaska....I'm of the opinion if Alaska
> can handle this type problem in the automation engine, that it would save on 
> a lot of support call problems and time.
> 
> By the way thanks for your reply. I will also post this where we are having 
> a dialogue on this issue.
> 
> Kind regards,
> Nestor
> 
> "IBA" <iba@adelphia.net> wrote in message 
> news:1260f0bd$32e1765a$5d2f5@news.alaska-software.com...
>> I am utilizing the ActiveX to connect with Word, Excel, IE and recently 
>> Crystal Reports.  I've found that certain ActiveXs that work well as small, 
>> stand-alone application, would crash a large one.  A simple ActiveX that 
>> only utilizes a few methods and variables of a COM-Object can be 
>> incorporated into a large application, but a bit more complex ActiveX can 
>> only run well as a small, stand-alone, dedicated application (It runs well 
>> as RunShell).  Incorporating the same procedure into a large application 
>> would crash it.  Years ago, I had similar problem with JazzAge, and the 
>> solution then was to RunShell() the ActivXs, but I was hoping that the 
>> release of SL1 would eliminate the need for multiple executables.
>>
>> Is there a better work-around this problem?
>>
>> Thank you, Alaska.
>>
>> -Itai
>>
>>
> 
>

Hi Jim,

Yes you are right...Thanks for clarifing that for me.

Kind regards,
Nestor

"James Loughner" <jwrl@suddenlink.net> wrote in message 
news:66390cf1$496fa98$7dc7@news.alaska-software.com...
> I'd say the problem is with the code that is doc'ed to return 128 but
> actually returns 400 causing a buffer overflow. When you pass a
> reference you are actually passing a memory address. The called routine
> then writes the return val at that address. There is nothing the calling
> routine can do to stop this since by the time the caller gets control
> back the damage has been done.
>
> Jim
>
>
> Nestor G. Torres wrote:
>> Hi Itai,
>>
>> After much batteling I have managed today to get my nomad activex calls 
>> to
>> become stable. I'm not sure who to blame.
>> My supplier of the activex in question spec'd field Var1 should be a 
>> string
>> of 32 bytes... var2 string 32 ...var3 string 128.
>> And that thes strings should be passed by reference@...
>>
>> Calling the activex with those parameters made my serial printer not work
>> after a while or with different sizes to run out of memory or freeze.
>>
>> After much adjusting and scratching my head i got to a setting of var1 
>> str
>> 38....  var2 str 38...var3 str 400...then it worked.
>> For example I was sending them a string by reference of 128 spaces and 
>> the
>> method would return 400 to my buffer string of 128
>> overwriting what i believe was the program executable code in memory.
>>
>> Now I believe these problems could have be resolved with the automation
>> engine from alaska....I'm of the opinion if Alaska
>> can handle this type problem in the automation engine, that it would save 
>> on
>> a lot of support call problems and time.
>>
>> By the way thanks for your reply. I will also post this where we are 
>> having
>> a dialogue on this issue.
>>
>> Kind regards,
>> Nestor
>>
>> "IBA" <iba@adelphia.net> wrote in message
>> news:1260f0bd$32e1765a$5d2f5@news.alaska-software.com...
>>> I am utilizing the ActiveX to connect with Word, Excel, IE and recently
>>> Crystal Reports.  I've found that certain ActiveXs that work well as 
>>> small,
>>> stand-alone application, would crash a large one.  A simple ActiveX that
>>> only utilizes a few methods and variables of a COM-Object can be
>>> incorporated into a large application, but a bit more complex ActiveX 
>>> can
>>> only run well as a small, stand-alone, dedicated application (It runs 
>>> well
>>> as RunShell).  Incorporating the same procedure into a large application
>>> would crash it.  Years ago, I had similar problem with JazzAge, and the
>>> solution then was to RunShell() the ActivXs, but I was hoping that the
>>> release of SL1 would eliminate the need for multiple executables.
>>>
>>> Is there a better work-around this problem?
>>>
>>> Thank you, Alaska.
>>>
>>> -Itai
>>>
>>>
>>
>>