[DUG] Debugging on TS

[Rohit Gupta]

You could always demo it in a DUG meeting :-)

From:           	"Max Nilson" <max at accredo.co.nz>
To:             	"'NZ Borland Developers Group - Delphi List'" <delphi at ns3.123.co.nz>
Subject:        	RE: [DUG] Debugging on TS
Date sent:      	Mon, 1 Aug 2005 11:41:30 +1200
Organization:   	Profax International Limited
Send reply to:  	max at accredo.co.nz,
  	NZ Borland Developers Group - Delphi List <delphi at ns3.123.co.nz>
	<mailto:delphi-request at ns3.123.co.nz?subject=unsubscribe>
	<mailto:delphi-request at ns3.123.co.nz?subject=subscribe>

[ Double-click this line for list subscription options ] 

Richard Vowles commented: 

> Ah, part of the never ending problem with Profax posting here 
> :-) They have invented all of this ultra-cool tech and they 
> talk about it but they simply aren't in the business of 
> having the resources to share it :-( 

Richard, you should come over some time and check out some of the seriously
cool new code that has been written this year! I'm sure Paul would like a
chance to show off the new stuff and brag a bit.

Anyway we know that this is a problem, and I appreciate that it is a pain
for you guys to forever be hearing that we have all this cool code. But as I
mentioned before we are focused on our application development and the
components and the like are the result of attempting to do RAD as best we
can. The principle goes that if we have had to write something three times
or more, then it should be factored out into a component or unit that is
shared.

I mostly post answers here, along with coding commentary, so that people
know that there is at least one solution to the problem under discussion.
Our solution fits our code base and requirement, and is usually very
interconnected with other parts of our code base. Even if I could post the
code in question the dependencies would be a pain in the ass to us all.

Sometime the code is very small and simple and can be posted directly, but
mostly the code under discussion is a fairly large entity. For example the
delayed event manager (only 250+ lines in several file) relies on our idle
time processing components (467 lines in one file plus calls from the main
application form). To provide this I'd either needs to remove the idle time
component dependency, convert it to the equivalent JEDI JVCL component, or
duplicate some of the other code.

After our initial foray into the component market we'll probably never do
the same again, but that does not mean that we are not open to offers or
opportunities for others to help us out here. If someone, or some company,
could show us that they could take our technology and sell it for a mutual
profit, then the directors would certainly like to hear from you 8-)

We have even discussed GPL or BSD licensing opportunities for our code, but
the two sticking point are the time required to separate out the various
nice bits from the application domain specific and document it all, and the
problem providing code to our direct competitors in the market who we know
write in Delphi and watch what we do just as carefully as we watch them.

Cheers, Max.



_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi
Regards

Rohit

======================================================================
CFL - Computer Fanatics Ltd.  21 Barry's Point Road, AKL, New Zealand
PH    (649) 489-2280 
FX    (649) 489-2290
email rohit at cfl.co.nz  or  r.gupta at xtra.co.nz
======================================================================