Alaska Software Inc. - This is not what we need. Can not agree with the others!
Username: Password:
AuthorTopic: This is not what we need. Can not agree with the others!
joerg bertramThis is not what we need. Can not agree with the others!
on Wed, 07 Jan 2004 18:24:08 +0100
I like to say:

Congratulations,now you have reached the point of  CA-Visual Objects 1.x:
 the applications may be stable, but they needed years to establish a stable
IDE.

I am not amused.

Here is why i say so hard words:


I have tryed vx today the first time:

compile/link with debug works:

than, i have got some problems:

1. any loaded prg-file is marked as
"file has modified, should it be saved"
but i did not change anything, (i tested it later with fc !)

2. a change in prg, which leads to an immediate compile/link/restart-cycle
is very very slow (>50 secs) . This feature is not usable (for me (now))

3. The object inspector crashes while inspecting an xbpocx-Object

-> This crash stops the debugged application ! without any error-logging
    I can not accept this behaviour, any debugging of the app becomes
dangerous because i can not
    be sure at which moment the debugger crashes, any cirumstances of my
application-test session are      gone in  that  moment

-> i did not found any errorlog of the vx20
-> the debugger/ide stops working any longer
-> it seems that there where pending changes of source not written to disc
-> i can not be sure, which way of "closing  the debugged app" the debugger
used when it crashed.

Jrg Bertram
Till WarwegRe: This is not what we need. Can not agree with the others!
on Thu, 08 Jan 2004 12:33:36 +0100
"joerg bertram" <jbertram@avis.de> wrote in message
news:5RjBRMU1DHA.3616@S15147418...
(...)
> 1. any loaded prg-file is marked as
> "file has modified, should it be saved"
> but i did not change anything, (i tested it later with fc !)
>
> 2. a change in prg, which leads to an immediate compile/link/restart-cycle
> is very very slow (>50 secs) . This feature is not usable (for me (now))
>
> 3. The object inspector crashes while inspecting an xbpocx-Object
>
> -> This crash stops the debugged application ! without any error-logging
>
> -> i did not found any errorlog of the vx20
> -> the debugger/ide stops working any longer
> -> it seems that there where pending changes of source not written to disc
> -> i can not be sure, which way of "closing  the debugged app" the
debugger
> used when it crashed.

Joerg,

firstofall, I'm sorry you're not satisfied with the pre-release.
I agree that such behaviour isn't acceptable! However, we are not
aware of the problems you describe nor has anybody else reported
anything similar.

If you're willing to risk another look, we'd be more than happy to
assist you in any way we can. Even if you don't, we're most interested
in any scenario you can give us for reproducing this. It may help if
we had an idea what your project file looks like. Also, this would
help us to guess why it takes so long compiling it. If this isn't a
problem with your installation, it must be fixed as soon as possible!

Regards,
  Till

--
---------------------------------------------------
ARD - Alaska Research & Development

Web:       http://www.alaska-research.com
Investors: http://www.alaska-research.com/tifund
E-Mail:    mailto:till.warweg@alaska-research.com
Contact:   mailto:info@alaska-research.com
---------------------------------------------------
Andreas Herdt Re: This is not what we need. Can not agree with the others!
on Thu, 08 Jan 2004 16:26:40 +0100
Hi Jörg,

joerg bertram wrote:
> I like to say:
> 
> Congratulations,now you have reached the point of  CA-Visual Objects 1.x:
>  the applications may be stable, but they needed years to establish a stable
> IDE.
> 
> I am not amused.
> 
> Here is why i say so hard words:
> 
> 
> I have tryed vx today the first time:
> 
> compile/link with debug works:
> 
> than, i have got some problems:
> 
> 1. any loaded prg-file is marked as
> "file has modified, should it be saved"
> but i did not change anything, (i tested it later with fc !)

We have been very confused by this behaviour, since it was not only you
who has reported this oddity. We have been even more confused about the 
fact that there have been many people poped up today and we have had
never seen the problem you have described in the past.
However, I think we have found the reason.

Solution:
Tools->Editor Options->IntelliCode Tabpage
uncheck Keywords in uppercase.

Thus the keyword transformation in uppercase will be disabled and the
sources are no longer modified when stepping through the sources.

The next VX that will be available tomorrow, has this checkmark unset
by default.

> 
> 2. a change in prg, which leads to an immediate compile/link/restart-cycle
> is very very slow (>50 secs) . This feature is not usable (for me (now))
> 
> 3. The object inspector crashes while inspecting an xbpocx-Object
> 
> -> This crash stops the debugged application ! without any error-logging
>     I can not accept this behaviour, any debugging of the app becomes
> dangerous because i can not
>     be sure at which moment the debugger crashes, any cirumstances of my
> application-test session are      gone in  that  moment

As Till allready pointed out, we would accept any help by your side that
enables us to solve the problem. I have used the VX the last days to do
some OCX stuff and I had none of the problems you have described.

What we know is that under rare circumstances, the VX crashes, so we
would be more then happy about a reproducable scenario. This would help
other customers, too.

> -> i did not found any errorlog of the vx20
> -> the debugger/ide stops working any longer
> -> it seems that there where pending changes of source not written to disc
> -> i can not be sure, which way of "closing  the debugged app" the debugger
> used when it crashed.
> 
> Jörg Bertram
> 
> 
> 
> 
> 
> 


Regards
   Andreas Herdt
   [Alaska Research & Development]
joerg bertramRe: This is not what we need. Can not agree with the others!
on Fri, 09 Jan 2004 13:04:30 +0100
Andreas!

I changed the behaviour of "intellicode" like you suggested.

It works!!

The other problems with "OCX" are disappeared today, but i suggest:

under any circumstances, the debugger should not kill or influence the
debuggee by accident
or vice versa:

-  to hold the testing sessions active for any reasons, (live time
debugging, testing results with other tools, long time data processing
tests, etc....)

- The second  to be able to save or discard modifications even when
debuggee/debugger crashed

One question:

Is it possible to attach a debugger session to a working application (for on
site debugging in case of runtime problems)

Jrg Bertram
Mike EvansRe: This is not what we need. Can not agree with the others!
on Fri, 09 Jan 2004 15:34:27 +0200
Joerg
I haven't the problems you have but i have seen strange thinks happen on my Win ME pc. The end key move the cursor to top of the
source code and not at the EOL. Also i have some crashes with not any obvious reason.  Under my other Win XP pc i have almost no
problem at all.

Regards
Mike Evans

"joerg bertram" <jbertram@avis.de> wrote in message news:tZ5M9iq1DHA.2164@S15147418...
> Andreas!
>
> I changed the behaviour of "intellicode" like you suggested.
>
> It works!!
>
> The other problems with "OCX" are disappeared today, but i suggest:
>
> under any circumstances, the debugger should not kill or influence the
> debuggee by accident
> or vice versa:
>
> -  to hold the testing sessions active for any reasons, (live time
> debugging, testing results with other tools, long time data processing
> tests, etc....)
>
> - The second  to be able to save or discard modifications even when
> debuggee/debugger crashed
>
> One question:
>
> Is it possible to attach a debugger session to a working application (for on
> site debugging in case of runtime problems)
>
> Jrg Bertram
>
>
Andreas Herdt Re: This is not what we need. Can not agree with the others!
on Fri, 09 Jan 2004 15:28:08 +0100
joerg bertram wrote:
> Andreas!
> 
> I changed the behaviour of "intellicode" like you suggested.
> 
> It works!!
> 
> The other problems with "OCX" are disappeared today, but i suggest:
> 
> under any circumstances, the debugger should not kill or influence the
> debuggee by accident
> or vice versa:
> 
> -  to hold the testing sessions active for any reasons, (live time
> debugging, testing results with other tools, long time data processing
> tests, etc....)
> 
> - The second  to be able to save or discard modifications even when
> debuggee/debugger crashed
> 
> One question:
> 
> Is it possible to attach a debugger session to a working application (for on
> site debugging in case of runtime problems)

It will be possible in one of the next releases or in Final release.

Regards
   Andreas Herdt
   [Alaska Research & Development]