Author | Topic: This is not what we need. Can not agree with the others! | |
---|---|---|
joerg bertram | This 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 Warweg | Re: 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 bertram | Re: 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 Evans | Re: 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] |