<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Comments for CodeGear - The Drive for Quality Products</title>
<link rel="alternate" type="text/plain" href="http://dn.codegear.com/article/33979" title="CodeGear - The Drive for Quality Products" />
<link rel="self" type="application/atom+xml" href="http://dn.codegear.com/article/33979/feed" title="Comments for CodeGear - The Drive for Quality Products" />
<id>http://dn.codegear.com/article/33979</id>
<updated>2008-10-11T05:57:25-07:00</updated>
<entry>
<title>re: CodeGear - The Drive for Quality Products</title>
<author>
<name>Chris Pattinson</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=39817</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=39817</id>
<updated>2007-01-19T14:04:09-08:00</updated>
<published>2007-01-19T14:04:09-08:00</published>
<summary>re: CodeGear - The Drive for Quality Products</summary>
<content>Thanks for the feedback, this is exactly what we're planning to run on a daily basis. The biggest project we have is our own code base, though a number of open source projects are also under consideration. </content>
</entry>
<entry>
<title>re: CodeGear - The Drive for Quality Products</title>
<author>
<name>Chris Pattinson</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=39816</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=39816</id>
<updated>2007-01-19T14:02:37-08:00</updated>
<published>2007-01-19T14:02:37-08:00</published>
<summary>re: CodeGear - The Drive for Quality Products</summary>
<content>We're planning to develop automated tests that use a number of the popular sets of components on a regular basis, and perform 'dirty' but reproduceable tests as appropriate. For later releases of the product, this may mean needing to work with vendors as when we change the compiler signature, the components would need to be rebuilt then provided to the testing group - so may not be fully automated unless we have agreements from components vendor to have access to their source code. Mouse hovering and focus tests - we do focus tests, especially as part of our automation to detect the focus of dialogs, however I'll look into what we do for mouse hovering. Thanks for the QC reference.The flickering appears fixed in current builds. Are you on the field test for our next release? Send me an email to chris.pattinson@codegear.com if you would be interested since we have a major drive to clean up exactly the sort of issues you have mentioned. The intent would be to verify what we see is fixed, is fixed in your environment too.</content>
</entry>
<entry>
<title>CodeGear - The Drive for Quality Products</title>
<author>
<name>C Johnson</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=39814</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=39814</id>
<updated>2007-01-18T19:10:47-08:00</updated>
<published>2007-01-18T19:10:47-08:00</published>
<summary>CodeGear - The Drive for Quality Products</summary>
<content>Try a few large projects and some basic editing&amp; Programming tasks for an hour, or flipping between building large project groups.Work on a project with components and few hundred thousand lines of code including a unit or two with 30 or 40 thousand lines of code and see how code insight performs.These are NORMAL day to day situations for me.  Basically, find the biggest open source project you can that uses indy, jvcl and a few other components and try working with it.</content>
</entry>
<entry>
<title>CodeGear - The Drive for Quality Products</title>
<author>
<name>Atle Smelvaer</name>
<uri>http://threads.codegear.com/threads/threads.exe/userall?commentid=39812</uri>
</author>
<id>http://threads.codegear.com/threads/threads.exe/view?commentid=39812</id>
<updated>2007-01-18T03:06:39-08:00</updated>
<published>2007-01-18T03:06:39-08:00</published>
<summary>CodeGear - The Drive for Quality Products</summary>
<content>What about testing against different installed packaged? Some design time packages, experts etc. can make many bugs surface not to mention speed problems. The form switching slowdown did not surface before you had a lot of components installed.Do you run tests with the complete JVCL installed (and JCL Experts), JediVCS, AQTime, DelphiSpeedUp (http://andy.jgknet.de/dspeedup/) or DDevExtensions (http://andy.jgknet.de/dspeedup/index.php?page=DDevExtensions)? I know there may be problems within these component packages, but many problems may also surface from BDS when using these. It could also give better insight on how to create more accurate error information if the problem lies within the component package and not in BDS.I think this is a very important thing to do because there are few developers that work with a clean BDS. We all have a lot of components installed, so tests should also be done on less clean systems.And do you have mouse hovering tests and window focus tests? I experience problems with form focus at times when hovering over the Object Inspector properties and getting hints. This happens when setting focus in special orders, happens on all sorts of design surfaces but more when working with module surfaces like TDatamodule and TWebmodule. The designer often goes bananas on the window focus, and I have to use F12/F11 to clear up the mess. This type of problem is very annoying (some explaining here, qc closed without actually fixing the complete problem: http://qc.codegear.com/wc/qcmain.aspx?d=13691)I also wondered if the flickering when switching design forms still exist (http://qc.codegear.com/wc/qcmain.aspx?d=30691). Another one of my daily annoyers.And this one introduced in one of the updates on BDS 2006:http://qc.codegear.com/wc/qcmain.aspx?d=27895One alarming problem created by the GUI designers: http://qc.codegear.com/wc/qcmain.aspx?d=23807</content>
</entry>
</feed>
