Board index » delphi » Re: Win32 Needs

Re: Win32 Needs


2006-08-31 04:11:30 AM
delphi251
"Nick Hodges (Borland/DTG)" <XXXX@XXXXX.COM>writes
Quote
Okay -- let's take a step back here.

What do you all think /hasn't/ been done that should have been done by
now for Win32 developers?
Unicode VCL gets my vote, too. That would be a big help.
 
 

Re: Win32 Needs

Quote
What do you all think /hasn't/ been done that should have been done by
now for Win32 developers?
My absolute #1:
- Fix as many bugs as possible in the VCL.
There are really serious bugs reported in Quality Central, but not even
openend.
Just an example: #2549
It has been reported in 2002! This is a hard-to-find but easy-to-fix bug.
- Improve the VCL controls.
just a few examples:
Theme support for TDBGrid.
TRichtEdit should support the newer RTF dlls.
Mouse scrolling for TDBCtrlGrid.
- Native support for Firebird database.
- Improve online-help.
 

Re: Win32 Needs

Quote
Simply delete "your" package cache keys (that's what the
JVCL-Installer does), or even more simply delete the whole "Package
Cache" registry key. BDS will recreate it for you on the next start.
Allrightie, much appreciated, thanks :-)
Lucian
 

Re: Win32 Needs

Quote
TRichtEdit should support the newer RTF dlls.
Good point, here.
Back in the pre-Internet days, when people were running 95, 98, etc., and
*never* updated OS patches, having a common denominator for things like the
RTF were understandable.
With automatic updates and workable manual updates, ComCtrls are much more
consistent and having updates to the newer features should be key.
 

Re: Win32 Needs

Brian Moelk writes:
Quote
We have class helpers in Win32.
Didn't Danny say a long time ago that they were a temporary thing.
Cheers
Dean
 

Re: Win32 Needs

"Danijel Tkalcec" writes:
Quote
"Don Strenczewilk" writes:
>Wouldn't it make more sense to have: s := 99.ToString; ?

How about s := 99; ?
I forgot to include a <bg>here. If you ask me, it is pretty easy to create
classes implementing your favourite methods as class functions/procedures.
There's no need to overthrow all existing code by changing that low-level
stuff at Delphi level, nor is there a need to add redundant classes to the
RTL.
- Danijel Tkalcec
 

Re: Win32 Needs

Andreas Hausladen writes:
Quote
>Please not partial classes. Still think they are an accident
>waiting to happen.

Weren't they introduces only to make the WinForms autogenerated code
go away from the .cs files? Because this is the only thing they would
make sense (due to the shortcomming of non-existing DFM files :-) )
That was the way I understood it. I have heard of their benefits but
the pitfalls seriously outweigh them IMO.
Cheers
Dean
 

Re: Win32 Needs

Quote
Okay -- let's take a step back here.

What do you all think /hasn't/ been done that should have been done by
now for Win32 developers?

- Generics
- Multipass compiler (for the uses circular reference)
- Namespace
- Bugs correction of Bold + some improvments :-)
- NO Together !! or being detachable
- better handling in DEBUG of the include file
- better support for memory leak
- better handling of packages by project/prj group
and maybe ....
- win64
- ...
Eddy POULLET
Brussels
 

Re: Win32 Needs

Nick Hodges (Borland/DTG) writes:
Quote
Okay -- let's take a step back here.

What do you all think /hasn't/ been done that should have been done by
now for Win32 developers?


Things that would actually make a difference to me are
ECO
Garbage collection
Sean
 

Re: Win32 Needs

prefer not--not unless they have a reason.
Ed Dressel
 

Re: Win32 Needs

Dean Hill writes:
Quote
>We have class helpers in Win32.

Didn't Danny say a long time ago that they were a temporary thing.
I don't recall.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Win32 Needs

Brian Moelk writes:
Quote
Dean Hill writes:
>Please not partial classes. Still think they are an accident
>waiting to happen.

We have class helpers in Win32.
Those are mixins, not partial classes. Still an accident waiting to
happen, perhaps, but a different wreck. :)
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it is good: tinyurl.com/7hgfr
 

Re: Win32 Needs

Quote
* extended, safer-to-use RTTI functions and libraries (many things can be
done, but everything is quite a bit arcane right now, could use wrappers
and helpers)
Mmmm, yes please to reflection (and possibly attributes?). Could this then
open the door to ECO on Win32 ?
Ian
 

Re: Win32 Needs

Dean Hill writes:
Quote
Didn't Danny say a long time ago that they were a temporary thing.
I don't think he said quite that. I think he said there are very few
things you should use them for.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it is good: tinyurl.com/7hgfr
 

Re: Win32 Needs

Quote
>>How about s := 99; ?
>>
>>- Danijel
Donald Shimoda writes:
Quote
Seems like C untyped way. No way.
Well, I don't think it would work in C either.
In C++ it would work, AND be typesafe.
It would work and be typesafe in Python too, but for different reasons.
Python and other dynamically typed languages would allow the operation
to succeed, and take its type with it (transforming S)
In this case C++ is closer to functional languages, using "type
inference". The operation is statically checked by the type system,
and only succeeds if there is a valid conversion.
I'm still not sure these other type-checking strategies are appropriate
for Delphi - the nature of the langauge is to be strongly typed with no
implicit conversions allowed. Function overloading opened the door a
crack, but I don't see a clamour for more. Generics may one day push
the crack a little wider, if they are signature based like in C++, or
not - if they are interface based like in C#.
I think the Delphi language type system is at its own particular 'sweet
spot' right now.
[While C++ is still a moving target, with the auto keyword extending
much closer to a type-inference based language in the next version.]
--
AlisdairM(TeamB)