Another Wish list

[Laurent Opprecht]

Wish list

VB should have better support for assertion. It would mean being able to
write post-assert and pre-assert for a class and for functions. Class
pre/post assert should be called before/after each public call. Ideally this
code should be separated from normal code using tabs to navigate between.

The same should be true for testing. VB should have a tab in the code
module of every class to insert testing code and a button to start tests.

VB should provide method/function/class documentation/help in the code
itself rather than trough the tools menu. Maybe in another tab. And VB
should be able to compile html help from that automatically.

A refactoring tool too would be a huge improvement, even for small
things such as method renaming. Of course you can do this refactoring with
search and replace but not in a secure way and there are more refactoring
than just method renaming. Such a tool should be able to tell you if a
refactoring is sure and propose refactoring as well.

A wizard for object composition.

Form layout should be improved to better support resizing. Java layout
managers are a good example of what could be done.

Functionality available in the IDE should be available to create
program. This include: icons in menu, docking forms, user defined drop down
for controls properties (such as the colour chooser of form.background),
etc.

Controls improvement:
A splitpanel.
A better grid with editing and much more.
Mouse enter and mouse exit events for every controls.
An outlook style menu control.
Backcolor for treeview (and for every control visible at run time).
User defined border object which could be added to every controls.
A bevel panel which is not discontinued (and with a windowless
version).
A bevel line.
A select computer combobox or a simple way to iterate the computers
on the network (without api calls).
The standard tab control should be a container.
When we change the name of a control events should be renamed.
More windowless version of the controls.
A control hierarchy.

The functionality VB provide through the IDE should be available in the
code itself. Which means:
A default instruction for the default property
Method description
A Hide instruction to hide member
etc.

Better Windows support.
All windows functions, constants and types should be available
simply by adding a reference to the project.
All windows events should be supported in the controls. After all if
they exist they have to be useful.
Windows should support subclass without crashing the IDE.
When Microsoft creates a new control such as the tree in Internet
Explorer they could let other people reuse it.
When Microsoft add a new dll it could provide a way to use if from
VB.

Control creation. You should be able to create typed collections the
same way you create arrays for example:
dim C as Collection of String
Better yet VB should support template to let people create their one
container and still provide the same mechanism
dim C as MyHashTable of Control

Support for user defined simple type:
Final to allow method inlining.
Operator overloading.
The possibility to work by value rather than reference.

A wizard for extracting "typed" recordset from tables, i.e. a class
witch extends recordset with properties corresponding to the table fields.

VB should provide a better navigator. A hierarchical property viewer for
such things as font properties. A properties/method view in the project
viewer with sort/hide on visibility attributes (public, protected, private).
A hierarchical view of the class one for inheritance and one for object
properties.

Let the Activate/lostfocus works when we switch from one application to
another or provide an application_lostFocus event. This is especially annoyi
ng when you switch from a form in a dll to a form in the main exe.

Better control of a control at design time to allow such things as
changing a tab by clicking at design time in a ssTab or detecting when the
user add a control to a container.

Better marshalling and an automatic way to move (or copy) an object
between process.

A hierarchical namespace. Well not only for VB but for COM like
Microsoft.ADO.Recordset.

Code timer.

Support for abstract method and interfaces.

Implementation of interfaces should be public.

Variable declaration should be compulsory.

VB should be completely object oriented. Without standard module.

Window should be object oriented.

More orthogonality. This is one of the things VB is missing the most. It
means that a rule should not have exceptions. Here are a few examples:
You cannot call AddressOf on class methods
Control class don't have any properties such as left, top, etc..
Printer don't have a print property but you can still call it
You cannot implement recordset
You cannot implement outgoing interfaces (events)
The form.Line (x1,y1)-(x2,y2).. method is a mystery
You can call sub without Parenthesis but not functions or better yet
the other way.
You have collections which starts at 0 and other at 1.
Controls works in different ways. Some have backcolor property other
not, etc.
Controls don't have the same bordure.
PrintScreen appears in keyDown but not in keyPress.
You can cancel a key in keyDown but not in keyPress (or the other
way around)
etc.

Stop to add things such as the form preview Window.

And I don't want pointers of any kind in VB apart for windows
compatibility. There is enough with polymorphism and events to escape that.

Laurent Opprecht

[Colin McGuigan]

Laurent Opprecht wrote in message <39211953@news.devx.com>...
>Wish list
>
> VB should have better support for assertion. It would mean being able
to
>write post-assert and pre-assert for a class and for functions. Class
>pre/post assert should be called before/after each public call. Ideally
this
>code should be separated from normal code using tabs to navigate between.

I agree that VB needs better assertion. I don't know what you mean by post-
and pre-asserts, though, and I really don't understand what you mean by
using a different tab. IMHO, a "better assert" would involve using
Debug.Assert the way it is, with
* A switch when compiling to leave the assertions in.
* An assertion at runtime returning the assertion, the statement that
failed, and a line number, eg, 'Assertion Failed (Line 162): Not obj Is
Nothing' Extra spiffiness points would include a callstack.

> The same should be true for testing. VB should have a tab in the code
>module of every class to insert testing code and a button to start tests.

I really don't know what you mean here, either.

> VB should provide method/function/class documentation/help in the code
>itself rather than trough the tools menu. Maybe in another tab. And VB
>should be able to compile html help from that automatically.

I think Microsoft should streamline it's help system; perhaps give us
two...old style VB help (a la VB5), and then MSDN everything, because each
has their uses. However, I prefer these to be seperate windows from VB,
since I can then use Alt-Tab to switch between them. If they were tabs, I'd
have to use the mouse.

> A refactoring tool too would be a huge improvement, even for small
>things such as method renaming. Of course you can do this refactoring with
>search and replace but not in a secure way and there are more refactoring
>than just method renaming. Such a tool should be able to tell you if a
>refactoring is sure and propose refactoring as well.

Hrmm. While it'd be nice (I guess) I don't see how it'd be implemented.

> A wizard for object composition.

Isn' this what the Class Builder add-in does?

> Form layout should be improved to better support resizing. Java layout
>managers are a good example of what could be done.

You mean, to resize constituent controls automatically upon itself being
resized? I don't think it's possible; several third party controls try to
do this, but there are always exceptions that end up breaking things.

> Functionality available in the IDE should be available to create
>program. This include: icons in menu, docking forms, user defined drop down
>for controls properties (such as the colour chooser of form.background),
>etc.

Heh. This is one of the nice things about Delphi; since Delphi is written
in Delphi, if they do it in the IDE, so can you. Anywhos, icons in menus
would be nice. Docking forms would be difficult to implement elegantly, me
thinks. And the color chooser would be nice, though I personally just use
the Common Dialog color chooser.

> Controls improvement:
> A splitpanel.

Free code exists for this everywhere. And it's marketed by at least one
component vendor that I know of.

> A better grid with editing and much more.

Many vendors.

> Mouse enter and mouse exit events for every controls.

Probable under W2k, but I don't think this would be backwards compatible
with Win9x and WinNT...therefore, I doubt we're going to see it. Mouse
Enter is easily kludged with a module or static variable, but Mouse Exit is
more of a pain than you might think, and is only possible (AFAIK) by using
the SetCapture API...which doesn't work if more than one hWnd is attempting
to use SetCapture.

> An outlook style menu control.

The Coolbar? Isn't that available in Common Controls 3 (6.0)?

> Backcolor for treeview (and for every control visible at run time).

While nice, some of the controls simply don't have this message defined.
DateTimePicker comes to mind.

> User defined border object which could be added to every controls.

What do you mean?

> A bevel panel which is not discontinued (and with a windowless
>version).
> A bevel line.

Don't know what you mean here, either.

> A select computer combobox or a simple way to iterate the computers
>on the network (without api calls).

HRmm. I guess. It can obviously be useful.

> The standard tab control should be a container.

Isn't it? Oh, you mean the one in Common Controls. Use Microsoft Tabbed
Dialog Control (tabctl32.ocx)

> When we change the name of a control events should be renamed.

Yes.

> More windowless version of the controls.

Like which ones? I doubt you'll see any of the more complex ones become
windowless...it kind of defeats the purpose.

> A control hierarchy.

What do you mean? Although this should be included, as VB7 will (from what
I hear) have control and form inheritance.

> The functionality VB provide through the IDE should be available in the
>code itself. Which means:
> A default instruction for the default property
> Method description
> A Hide instruction to hide member
> etc.

Yes. I think these could be implemented as keywords, eg:

Default Public Property Get Item(varIndex As Variant) As Variant

Hidden Enumerator Public Property NewEnum() As IEnumVARIANT

> Better Windows support.
> All windows functions, constants and types should be available
>simply by adding a reference to the project.

win.tlb. =)

Well, ok, it's not perfect, but it is handy.

> All windows events should be supported in the controls. After all
if
>they exist they have to be useful.

That's a huge amount of overhead, really. What I think would be more useful
would be a way to hook the WinProc in code, and then you can get that only
little message you need handily. But to expose hundreds of events that one
in ten thousand might use...eh.

> Windows should support subclass without crashing the IDE.

We'll have to see how ingenious they are. This isn't a problem with
subclassing, it's a problem with re-entrant callbacks and general
multithreading. Since VB7's going to support multithreading...should be
interesting.

> When Microsoft creates a new control such as the tree in Internet
>Explorer they could let other people reuse it.

Laugh.

> When Microsoft add a new dll it could provide a way to use if from
>VB.

You can. Add a reference to the DLL.

> Control creation. You should be able to create typed collections the
>same way you create arrays for example:
> dim C as Collection of String

Collections aren't typed, though. In order to make a collection typed (and
gain any sort of speed improvement from it), you'd have to have a different
interface for each type. And a new one created for every new conceivable
type that came out. I suppose you could kludge this by not making it an
object, but that opens up whole new cans of worms.

> Better yet VB should support template to let people create their one
>container and still provide the same mechanism
> dim C as MyHashTable of Control

As above.

> Support for user defined simple type:
> Final to allow method inlining.

Please explain.

> Operator overloading.

For a UDT? I don't think it'll happen.

> The possibility to work by value rather than reference.

It'd be nice. VB does it when you assign one UDT to another...so I don't
think this one should be a problem.

> A wizard for extracting "typed" recordset from tables, i.e. a class
>witch extends recordset with properties corresponding to the table fields.

So instead of calling rs("CustomerID") you call rs.CustomerID? Nifty, but
not really all that useful...any significant business object work, IMHO,
would require a different take on the objects that I don't see as happening
if they extend recordset (which would allow unvalidated, unrestricted access
to the data).

> VB should provide a better navigator. A hierarchical property viewer
for
>such things as font properties. A properties/method view in the project
>viewer with sort/hide on visibility attributes (public, protected,
private).
>A hierarchical view of the class one for inheritance and one for object
>properties.

Yep.

> Let the Activate/lostfocus works when we switch from one application to
>another or provide an application_lostFocus event. This is especially
annoyi
>ng when you switch from a form in a dll to a form in the main exe.

Not a problem that's ever plagued me, but I've heard it discussed often
enough. =)

> Better control of a control at design time to allow such things as
>changing a tab by clicking at design time in a ssTab or detecting when the
>user add a control to a container.

tabctl32.ocx does this (the changing tabs at design time). Why would it
matter if the user added a control at design time, though?

> Better marshalling and an automatic way to move (or copy) an object
>between process.

An automatic way of cloning objects isn't going to happen. Actually, I take
that back; it could be implemented so that VB will build clone methods for
you, but I wouldn't want it to. Too many small things that could go wrong
that I'd rather have control over.

> A hierarchical namespace. Well not only for VB but for COM like
>Microsoft.ADO.Recordset.

Outside the scope of VB, I'm afraid.

> Code timer.

XTimers

> Support for abstract method and interfaces.

What's an abstract method? As for interfaces, I agree. PublicNotCreatable,
while close, isn't eally what I'm looking for. =P

> Implementation of interfaces should be public.

Aren't they?

> Variable declaration should be compulsory.

Not going to happen; would break too much code. Just use Option Explicit
(and make sure 'Require Variable Declaration' is set in your Options)

> VB should be completely object oriented. Without standard module.

What's the difference between a standard BAS module, and a static class that
has only static methods? Why is one OO and one not?

> Window should be object oriented.

Laugh.

> More orthogonality. This is one of the things VB is missing the most.
It
>means that a rule should not have exceptions. Here are a few examples:
> You cannot call AddressOf on class methods

Hopefully this will be done in VB7, and I've heard some rumors about it.

> Control class don't have any properties such as left, top, etc..

These are provided by the Extender class, an example of where VB handles
things behind the scenes for you. Still want that automatic cloning done,
too?

> Printer don't have a print property but you can still call it

It does have it, it's just hidden, IIRC.

> You cannot implement recordset

Nor Collection. =(

> You cannot implement outgoing interfaces (events)

That's a whole nother can of worms. There's a large thread going on about
the subject.

> The form.Line (x1,y1)-(x2,y2).. method is a mystery

Legacy code dating back to QuickBasic. Same thing with InStr (which has an
Optional argument _first_)

> You can call sub without Parenthesis but not functions or better
yet
>the other way.

You can call anything without parenthesis if you're not doing anything with
the return value:
MySub 3
MyFunction 3

You only need the parenthesis when you are returning a value (even if the
value gets ignored):
Call MySub(3)
x = MyFunction(3)

> You have collections which starts at 0 and other at 1.

All collections atart at 1. It's arrays that tend to start at 0. Which,
for compatibility reasons, I don't think we'll ever see fixed.

> Controls works in different ways. Some have backcolor property
other
>not, etc.

Yep. Don't think it's going to change.

> Controls don't have the same bordure.

Ditto.

> PrintScreen appears in keyDown but not in keyPress.

That's a new one on me. =)

> You can cancel a key in keyDown but not in keyPress (or the other
>way around)

You can cancel it in KeyPress by setting KeyAscii to 0. Not sure about
KeyDown.

> etc.
>
> Stop to add things such as the form preview Window.

What's the Form Preview window?

> And I don't want pointers of any kind in VB apart for windows
>compatibility. There is enough with polymorphism and events to escape that.

Well, if you don't want them except for Windows compatibility, doesn't that
mean that you want them?

>Laurent Opprecht


--
Colin McGuigan

[Laurent Opprecht]

Oops I did not think I was clear enough.


Colin McGuigan <colin@chicor.com> wrote in message
news:39215fac$1@news.devx.com...
> Laurent Opprecht wrote in message <39211953@news.devx.com>...
> >Wish list
> >
> > VB should have better support for assertion. It would mean being able
> to
> >write post-assert and pre-assert for a class and for functions. Class
> >pre/post assert should be called before/after each public call. Ideally
> this
> >code should be separated from normal code using tabs to navigate between.
>

A class pre-assert is a class defined assertion which is automatically
called
before a public call is done. The class post-assert is the same thing but is
called after a public call is done. It allow you to define class rules and
assure their are enforced. Then you could need to add specific assertion to
a public call (most of the time you only need that for public call). When
you compile this calls are removed. Since the code you write for this
assertions could grow quite a bit we could add a tab in the code pane to
separate code assertion from "normal" code. The tab code navigation is
implemented in Delphi (or was it JBuilder or something else?).

> I agree that VB needs better assertion. I don't know what you mean by
post-
> and pre-asserts, though, and I really don't understand what you mean by
> using a different tab. IMHO, a "better assert" would involve using
> Debug.Assert the way it is, with
> * A switch when compiling to leave the assertions in.
> * An assertion at runtime returning the assertion, the statement that
> failed, and a line number, eg, 'Assertion Failed (Line 162): Not obj Is
> Nothing' Extra spiffiness points would include a callstack.
>
> > The same should be true for testing. VB should have a tab in the code
> >module of every class to insert testing code and a button to start tests.
>
> I really don't know what you mean here, either.

When it comes to write tests two ways of doing it exist. Either you create
auto testing classes and you add your tests to the class or you create a
separate testing class for each class you test. The first way you end up
with huge classes the other way you end up with a lot of classes. For this
reason it would be nice to have a tabbed code pane to separate the
"productive" code from the test code. Then running tests should be done
easily from the IDE because to be useful you have to run them allot. Notice
that I am not speaking about quality testing tests which are usually done by
another team when code is (more or less) finished.

You are right, I thing we should be able to access the call stack, if only
to report an error at run time and log it.

Oh and I don't know what you mean by IMHO.

>
> > VB should provide method/function/class documentation/help in the
code
> >itself rather than trough the tools menu. Maybe in another tab. And VB
> >should be able to compile html help from that automatically.
>
> I think Microsoft should streamline it's help system; perhaps give us
> two...old style VB help (a la VB5), and then MSDN everything, because each
> has their uses. However, I prefer these to be separate windows from VB,
> since I can then use Alt-Tab to switch between them. If they were tabs,
I'd
> have to use the mouse.

I think they could give us a small shortcut such as Ctrl+Tab to navigate
between the tabs. As for the help system yes they could really decide what
they want to do with it and streamlined it, as for the old VB5 help system I
found it was more mature.

>
> > A refactoring tool too would be a huge improvement, even for small
> >things such as method renaming. Of course you can do this refactoring
with
> >search and replace but not in a secure way and there are more refactoring
> >than just method renaming. Such a tool should be able to tell you if a
> >refactoring is sure and propose refactoring as well.
>
> Hrmm. While it'd be nice (I guess) I don't see how it'd be implemented.

It is not that much complicated (compared to VB) because much refactoring
are small one and are automatic. For example for method renaming the
compiler can determine every call to the method (some programming language
already allow you to navigate between the calls) and make and intelligent
search and replace (very easy). For extracting method the tool search for
long method then search for common code patterns. After that it propose you
to extract the code and ask you name of the new methods. Signature is
determine by variables used inside the code fragment and initialized
outside, return values are determine by modifications reused outside of the
code fragment etc.. Then the tools can ask you to replace instances of the
code fragment by a new method call and do it automatically (very easy too).
The difficult here part is to analyze the code (which is something the
compiler is already doing) but the replacement part is very easy. What 's
more extracting method is one of the most difficult refactoring (at least
from what I can foresee). The great advantage here is that refactoring are
secured and automatic work is done very fast. Some tries have already being
done it this direction.

>
> > A wizard for object composition.
>
> Isn' this what the Class Builder add-in does?
>

Never found that one very useful but if I can do it let me know. The idea is
that when you want to implement an interface the wizard creates a private
delegate variable and implement the interface by delegating the calls to the
delegate creating the code automatically. A lot of very boring work
otherwise.


> > Form layout should be improved to better support resizing. Java
layout
> >managers are a good example of what could be done.
>
> You mean, to resize constituent controls automatically upon itself being
> resized? I don't think it's possible; several third party controls try to
> do this, but there are always exceptions that end up breaking things.

The layout managers of java are more specific they allow you to put
constraint on controls such as the align property of picturebox but with
more freedom. You achieve your layout by putting panels in panels with
different layout managers, so you decide how your form will be layed. Of
course it is not completely automatic but far more useful than writing your
own code.

>
> > Functionality available in the IDE should be available to create
> >program. This include: icons in menu, docking forms, user defined drop
down
> >for controls properties (such as the color chooser of form.background),
> >etc.
>
> Heh. This is one of the nice things about Delphi; since Delphi is written
> in Delphi, if they do it in the IDE, so can you. Anywhos, icons in menus
> would be nice. Docking forms would be difficult to implement elegantly,
me
> thinks. And the color chooser would be nice, though I personally just use
> the Common Dialog color chooser.

Yes you are right Delphi is a great tool and a lot less frustrating in this
area. I use the Common Dialog color chooser too and its OK. But the problem
is when you want to copy the behavior of the listitem (not sure of the name)
property of a listbox, now ways (at least easily).

>
> > Controls improvement:
> > A splitpanel.
>
> Free code exists for this everywhere. And it's marketed by at least one
> component vendor that I know of.

Yes freecode exists but they are nearly all simple panels (with two controls
only) and missing runtime properties (to add a control at run time for
example). Yes you could buy one but it so useful I think one should be
included in VB. Ok you can laugh at me because I am a bit naive.

>
> > A better grid with editing and much more.
>
> Many vendors.

Yes but expensive and with tree grids (that I know of) in VB I think one
could be working a bit better. The best thing would be for Microsoft to
license the VSxxx (no publicity) grid and ship it with VB. Ok laugh at me
here too.

>
> > Mouse enter and mouse exit events for every controls.
>
> Probable under W2k, but I don't think this would be backwards compatible
> with Win9x and WinNT...therefore, I doubt we're going to see it. Mouse
> Enter is easily kludged with a module or static variable, but Mouse Exit
is
> more of a pain than you might think, and is only possible (AFAIK) by using
> the SetCapture API...which doesn't work if more than one hWnd is
attempting
> to use SetCapture.

If I remember well the mouse enter and mouse exit are available in NT and 95
(could make a mistake here). And yes mouse exit is a pain.
Sorry but I don't know what you mean by AFAIK.

>
> > An outlook style menu control.
>
> The Coolbar? Isn't that available in Common Controls 3 (6.0)?

I was thinking about the menu vertical at the left. Sorry but I don't know
how call it.

>
> > Backcolor for treeview (and for every control visible at run
time).
>
> While nice, some of the controls simply don't have this message defined.
> DateTimePicker comes to mind.

Yes but still I think DateTimePicket could do with a little BackColor
property.

>
> > User defined border object which could be added to every
controls.
>
> What do you mean?

Let provide an interface for borders and let have a read write property on
controls to handle drawing the border like with Swing in Java (if I remember
right). Ok it would not be easy and I am not counting on that but it would
be nice.

>
> > A bevel panel which is not discontinued (and with a windowless
> >version).
> > A bevel line.
>

SSpanel and other 3D controls are discontinued. Creating an etched line
(like the frame control do) oblige you to draw two lines of two different
colors, quite annoying.

> Don't know what you mean here, either.
>
> > A select computer combobox or a simple way to iterate the
computers
> >on the network (without api calls).
>
> HRmm. I guess. It can obviously be useful.
>
> > The standard tab control should be a container.
>
> Isn't it? Oh, you mean the one in Common Controls. Use Microsoft Tabbed
> Dialog Control (tabctl32.ocx)

Yes the SSTab, but with two controls doing the same thing I am a bit afraid
that one will disappear one day.

>
> > When we change the name of a control events should be renamed.
>
> Yes.
>
> > More windowless version of the controls.
>
> Like which ones? I doubt you'll see any of the more complex ones become
> windowless...it kind of defeats the purpose.

True but circumstances exist when it is useful to have windowless version.
Especially when you are creating your own control or needing a lot of
controls in a form.

>
> > A control hierarchy.
>
> What do you mean? Although this should be included, as VB7 will (from
what
> I hear) have control and form inheritance.

The same thing you find in VC++ and nearly everywhere. First a control class
with left, right, etc. properties which other controls extends then a parent
container class for containers, etc.

>
> > The functionality VB provide through the IDE should be available in
the
> >code itself. Which means:
> > A default instruction for the default property
> > Method description
> > A Hide instruction to hide member
> > etc.
>
> Yes. I think these could be implemented as keywords, eg:
>
> Default Public Property Get Item(varIndex As Variant) As Variant
>
> Hidden Enumerator Public Property NewEnum() As IEnumVARIANT
¨
A good example.

> > Better Windows support.
> > All windows functions, constants and types should be available
> >simply by adding a reference to the project.
>
> win.tlb. =)

Didn't know about this one. Could you explained?

>
> Well, ok, it's not perfect, but it is handy.
>
> > All windows events should be supported in the controls. After all
> if
> >they exist they have to be useful.
>
> That's a huge amount of overhead, really. What I think would be more
useful
> would be a way to hook the WinProc in code, and then you can get that only
> little message you need handily. But to expose hundreds of events that
one
> in ten thousand might use...eh.

Yes it would add a lot of complexity

>
> > Windows should support subclass without crashing the IDE.
>
> We'll have to see how ingenious they are. This isn't a problem with
> subclassing, it's a problem with re-entrant callbacks and general
> multithreading. Since VB7's going to support multithreading...should be
> interesting.

Sure multithreading is a pain in VB.

>
> > When Microsoft creates a new control such as the tree in Internet
> >Explorer they could let other people reuse it.
>
> Laugh.

Maybe I am a bit naive about this one?

>
> > When Microsoft add a new dll it could provide a way to use if
from
> >VB.
>
> You can. Add a reference to the DLL.

Here is a small problem: I would like to be able discover an object
interface at run time. Number of functions, function names, signatures etc..
For that I need to use IDispatch and I am a bit lost. The idea is to create
the implementation/delegation wizard myself. If you have a solution it is
welcome.

>
> > Control creation. You should be able to create typed collections the
> >same way you create arrays for example:
> > dim C as Collection of String
>
> Collections aren't typed, though. In order to make a collection typed
(and
> gain any sort of speed improvement from it), you'd have to have a
different
> interface for each type. And a new one created for every new conceivable
> type that came out. I suppose you could kludge this by not making it an
> object, but that opens up whole new cans of worms.
>
> > Better yet VB should support template to let people create their one
> >container and still provide the same mechanism
> > dim C as MyHashTable of Control
>
> As above.

A solution exist in C++ with templates. You create a class where one of the
variable is a class itself (more or less). Then the preprocessor
automatically generates a new class whenever you need it. One for collection
of string, one for collection of integer, etc. Very nice solution.

>
> > Support for user defined simple type:
> > Final to allow method inlining.
>

You cannot inline a polimorphic method because you don't know at compile
time which one will be called (the actual address is looked up at run time
in the v-table). If you know the method that will be called the compiler can
decide to inline it (i.e. copy the assemble code rather than doing a full
call). The final keyword mark the method as not being polimorphic which
makes it a candidate to be inlined (the drawback is that you cannot overload
it anymore).

> Please explain.
>
> > Operator overloading.
>
> For a UDT? I don't think it'll happen.

Me neither but for simple types it would be so beautiful.

>
> > The possibility to work by value rather than reference.
>
> It'd be nice. VB does it when you assign one UDT to another...so I don't
> think this one should be a problem.
>
> > A wizard for extracting "typed" recordset from tables, i.e. a class
> >witch extends recordset with properties corresponding to the table
fields.
>
> So instead of calling rs("CustomerID") you call rs.CustomerID? Nifty, but
> not really all that useful...any significant business object work, IMHO,
> would require a different take on the objects that I don't see as
happening
> if they extend recordset (which would allow unvalidated, unrestricted
access
> to the data).

Sure it is not that useful especially if you have to do it by hand. But it
can be faster (calling rs(1) is faster than rs("CustormerID")) and you win
the intellisense help. Of course it is just low layer upon which you need to
create you own business model (without inheriting recordset).

>
> > VB should provide a better navigator. A hierarchical property viewer
> for
> >such things as font properties. A properties/method view in the project
> >viewer with sort/hide on visibility attributes (public, protected,
> private).
> >A hierarchical view of the class one for inheritance and one for object
> >properties.
>
> Yep.
>
> > Let the Activate/lostfocus works when we switch from one application
to
> >another or provide an application_lostFocus event. This is especially
> annoyi
> >ng when you switch from a form in a dll to a form in the main exe.
>
> Not a problem that's ever plagued me, but I've heard it discussed often
> enough. =)

The problem is when you have a form in a Dll you want to hide when the user
switch, either to the main application, or to another application. The event
don't fire.

>
> > Better control of a control at design time to allow such things as
> >changing a tab by clicking at design time in a ssTab or detecting when
the
> >user add a control to a container.
>
> tabctl32.ocx does this (the changing tabs at design time). Why would it
> matter if the user added a control at design time, though?

Yes but I don't know how they did it.
If you create a splitpanel you could want to resize added controls at design
time.

>
> > Better marshalling and an automatic way to move (or copy) an object
> >between process.
>
> An automatic way of cloning objects isn't going to happen. Actually, I
take
> that back; it could be implemented so that VB will build clone methods for
> you, but I wouldn't want it to. Too many small things that could go wrong
> that I'd rather have control over.

Yes a copy constructor would be nice.

>
> > A hierarchical namespace. Well not only for VB but for COM like
> >Microsoft.ADO.Recordset.
>
> Outside the scope of VB, I'm afraid.

Sure but Java packages are so beautiful. And it so nice to have (sort of)
dlls for your dlls. And I would really like to have the add reference
window presented with a tree.

> > Code timer.
>
> XTimers

Crash the IDE all the time. Especially when debugging.

>
> > Support for abstract method and interfaces.

An abstract method is close to a typed function pointer. You just declare
the signature and the name without the implementation. Still it is part of
the interface so you can write code that call it. It is the responsibility
of the subclasses to provide the actual implementation by overloading the
function.

> What's an abstract method? As for interfaces, I agree.
PublicNotCreatable,
> while close, isn't eally what I'm looking for. =P
>
> > Implementation of interfaces should be public.

> Aren't they?

I was not very clear about this one. What I want is to be able to call
methods on an interface without having to get through another typed object
like that

dim o As MyClass 'My class implements MyInterface
o.AmethodOnMyClass
o.AmethodeOnMyInterface

>
> > Variable declaration should be compulsory.
>
> Not going to happen; would break too much code. Just use Option Explicit
> (and make sure 'Require Variable Declaration' is set in your Options)

I am afraid you are right about this one. But I cannot understand how
someone could ever dream of witting code without declaring it variables.
(Apart form scripting)

>
> > VB should be completely object oriented. Without standard module.
>
> What's the difference between a standard BAS module, and a static class
that
> has only static methods? Why is one OO and one not?

True you can write procedural code with object oriented languages (which is
something you should avoid) but it is more difficult because it goes against
the philosophy of the language. Putting a static method in class is better
if
it is related to the class so everything is in one place (try to implement
the singleton pattern (a class that can be created only once) in VB and
compare it with solution using static method in the class). What's more I
think that a language should forbid you to do dangerous constructions (such
as not declaring variables). I know that many programmers will disagree with
me on that saying you just have to use it the right way. The problem if you
leave standard module in VB is that most people will never use objects and
go on writing procedural code forever. Of course I don't think it will ever
happen. What's more, from time to time, if you want to improve you have to
break up backward compatibility and get rid of the mistakes of the past.
Best
example: Java. Strangely it is providing more or less the same
functionalities (more for now) than VB (I am speaking about the language)
but it is far more structured and is easier to learn (and VB is supposed to
be basic).

>
> > Window should be object oriented.
>
> Laugh.

I follow you on this one.

>
> > More orthogonality. This is one of the things VB is missing the most.
> It
> >means that a rule should not have exceptions. Here are a few examples:
> > You cannot call AddressOf on class methods
>
> Hopefully this will be done in VB7, and I've heard some rumors about it.

It will really help with (Windows) subclassing.

>
> > Control class don't have any properties such as left, top, etc..
>
> These are provided by the Extender class, an example of where VB handles
> things behind the scenes for you. Still want that automatic cloning done,
> too?

Oh yes because you would put the extender methods in the control class an
inherit from that. On the second thought I don't want automatic cloning if I
cannot change it if I need it (that's why we need copy constructors).

>
> > Printer don't have a print property but you can still call it
>
> It does have it, it's just hidden, IIRC.

What do you mean by IIRC?

>
> > You cannot implement recordset
>
> Nor Collection. =(
>
> > You cannot implement outgoing interfaces (events)
>
> That's a whole nother can of worms. There's a large thread going on about
> the subject.

Ok you could need not to implement events (event if I don't know why) but
not being able to implement them when you need it is breaking the interface
contract.

>
> > The form.Line (x1,y1)-(x2,y2).. method is a mystery
>
> Legacy code dating back to QuickBasic. Same thing with InStr (which has
an
> Optional argument _first_)

Nice one to add to my collection of VB horrors.

>
> > You can call sub without Parenthesis but not functions or better
> yet
> >the other way.
>
> You can call anything without parenthesis if you're not doing anything
with
> the return value:
> MySub 3
> MyFunction 3
>
> You only need the parenthesis when you are returning a value (even if the
> value gets ignored):
> Call MySub(3)
> x = MyFunction(3)

To be honest I have never been able to be used to calling sub without
parenthesis. That's why it is bothering me so much.

>
> > You have collections which starts at 0 and other at 1.
>
> All collections atart at 1. It's arrays that tend to start at 0. Which,
> for compatibility reasons, I don't think we'll ever see fixed.

Why to start arrays at 0 and collections at 1? What's more when you are
using components from time to time their collections start at 1 and
otherwise they start at 0. If I remember right the VB Forms collection
starts
at 0.

> > Controls works in different ways. Some have backcolor property
> other
> >not, etc.
>
> Yep. Don't think it's going to change.

Neither me.

>
> > Controls don't have the same bordure.
>
> Ditto.
>
> > PrintScreen appears in keyDown but not in keyPress.
>
> That's a new one on me. =)
>
> > You can cancel a key in keyDown but not in keyPress (or the other
> >way around)
>
> You can cancel it in KeyPress by setting KeyAscii to 0. Not sure about
> KeyDown.
>
> > etc.
> >
> > Stop to add things such as the form preview Window.
>
> What's the Form Preview window?

In French it is called "présentation de feuille" (don't know how to call it
in English). It is this useless thing which allows you to decide where your
forms will appear at start up.

>
> > And I don't want pointers of any kind in VB apart for windows
> >compatibility. There is enough with polymorphism and events to escape
that.
>
> Well, if you don't want them except for Windows compatibility, doesn't
that
> mean that you want them?

Oops don't misunderstand me we need the addressOf for callback but that's
all I am ready to accept from pointers. I am just a bit afraid because every
now and then you find someone asking for string pointers, or wanting to go
around Com reference count to avoid circular references (you can use a
wrapper for that). Pointers and memory management are alright for low level
languages or when your primary concern is about performance but it adds a
lot
of work and a lot of stupid and difficult to find bugs. So I would rather
keep then off VB.

>
> >Laurent Opprecht
>
>
> --
> Colin McGuigan
>
>
>

Laurent Opprecht

[Colin McGuigan]

Laurent Opprecht wrote in message <3922726a@news.devx.com>...
>Oops I did not think I was clear enough.
>
>A class pre-assert is a class defined assertion which is automatically
>called
>before a public call is done. The class post-assert is the same thing but
is
>called after a public call is done. It allow you to define class rules and
>assure their are enforced. Then you could need to add specific assertion to
>a public call (most of the time you only need that for public call). When
>you compile this calls are removed. Since the code you write for this
>assertions could grow quite a bit we could add a tab in the code pane to
>separate code assertion from "normal" code. The tab code navigation is
>implemented in Delphi (or was it JBuilder or something else?).

Ah. So it's an assertion that's tested before or after any call to a
specified object? Yes, that could be useful.

>When it comes to write tests two ways of doing it exist. Either you create
>auto testing classes and you add your tests to the class or you create a
>separate testing class for each class you test. The first way you end up
>with huge classes the other way you end up with a lot of classes. For this
>reason it would be nice to have a tabbed code pane to separate the
>"productive" code from the test code. Then running tests should be done
>easily from the IDE because to be useful you have to run them allot. Notice
>that I am not speaking about quality testing tests which are usually done
by
>another team when code is (more or less) finished.

I don't really write that much 'test' code...but I do think that the ability
to group pages of code into different tabs might be _very_ useful; eg, I
read this, and I think of grouping my control events into one tab, my own
subroutines and functions into another, and my form events into yet another.

>Oh and I don't know what you mean by IMHO.

In My Honest Opinion (or, another derivative, In My Humble Opinion)

>I think they could give us a small shortcut such as Ctrl+Tab to navigate
>between the tabs. As for the help system yes they could really decide what
>they want to do with it and streamlined it, as for the old VB5 help system
I
>found it was more mature.

It was more mature, better organized, and faster. Now I accidentally hit F1
and spend five seconds waiting for the screen to come up telling me the
keyword's not recognized. =P Ctrl-Tab's a possibility; perhaps F1 could
simply be used to both open up the help window, switch to it if it's already
open, or switch back. That could work.

<snip stuff on refactoring>

>Never found that one very useful but if I can do it let me know. The idea
is
>that when you want to implement an interface the wizard creates a private
>delegate variable and implement the interface by delegating the calls to
the
>delegate creating the code automatically. A lot of very boring work
>otherwise.

I don't think it's (the Class Wizard) very useful, and I don't think it
handles interfaces...but it does do public properties of private variables,
and a quick search 'n' replace for 'Public' to 'Private IMyInterface_'
should do the trick.

<stuff about layout snipped>

<stuff about controls snipped>

>Yes freecode exists but they are nearly all simple panels (with two
controls
>only) and missing runtime properties (to add a control at run time for
>example). Yes you could buy one but it so useful I think one should be
>included in VB. Ok you can laugh at me because I am a bit naive.

I've never used it, but I believe that VideoSoft's VSFlex does what you're
asking. They are useful, but, to be quite honest, I'd prefer that Microsoft
not put all these controls into VB. It'd bloat the VB runtimes worse than
they are. Maybe as seperate OCXes (much like tabctl32.ocx, etc), though.

>Yes but expensive and with tree grids (that I know of) in VB I think one
>could be working a bit better. The best thing would be for Microsoft to
>license the VSxxx (no publicity) grid and ship it with VB. Ok laugh at me
>here too.

Ditto as above.

>If I remember well the mouse enter and mouse exit are available in NT and
95
>(could make a mistake here). And yes mouse exit is a pain.

Close; TrackMouseEvent is available in NT and 98, but not 95. So I stil
don't think we'll see it...

>Sorry but I don't know what you mean by AFAIK.

As Far As I Know

>Yes but still I think DateTimePicket could do with a little BackColor
>property.

It'd be nice, but my point was that it was outside the realm of VB.

<snip stuff about control appearance>


>Yes the SSTab, but with two controls doing the same thing I am a bit afraid
>that one will disappear one day.

Never had a problem so far.

>True but circumstances exist when it is useful to have windowless version.
>Especially when you are creating your own control or needing a lot of
>controls in a form.

My point was that as a windowless control gets more complex, you get less of
a savings in resources from using it, up to the point where someone is
basically rewriting everything that Windows does.

>The same thing you find in VC++ and nearly everywhere. First a control
class
>with left, right, etc. properties which other controls extends then a
parent
>container class for containers, etc.

I don't know if this'll happen. I think it'd be great, but too much legacy
code is wrapped up with the Extender object.

>Didn't know about this one. Could you explained?

win.tlb is a type library containing constants and declares for a good deal
(but not all of) the Windows API. You can download it at
www.themandelbrotset.com. You'll need to add it to a project under
'References'.

>Maybe I am a bit naive about this one?

I'm sorry. It's just that I'm also in a discussion in talk.editors.vbpj
about this subject, and how Microsoft has a history of doing something with
the OS, and then not releasing it for a couple of months (if ever) to
everyone else.

>Here is a small problem: I would like to be able discover an object
>interface at run time. Number of functions, function names, signatures
etc..
>For that I need to use IDispatch and I am a bit lost. The idea is to create
>the implementation/delegation wizard myself. If you have a solution it is
>welcome.

If you don't know an object's interface at run-time, how are you ever going
to use it effectively? I find that reflection is useful for a programming
environment, a scripting environment, or something along those lines, but I
can't imagine how you'd have an already existing program that, without
rewriting/recompiling, could be made to take advantage of a totally new DLL.

But, you can inspect COM objects by using the interfaces exposed in
tblinf32.tbl. Do a search for this and 'tblinf32.chm' in a search engine,
and you should be able to come up with a better explanation.

>A solution exist in C++ with templates. You create a class where one of the
>variable is a class itself (more or less). Then the preprocessor
>automatically generates a new class whenever you need it. One for
collection
>of string, one for collection of integer, etc. Very nice solution.

Not aware of this one. It stills sounds like it'd be bloat to me, though.

>You cannot inline a polimorphic method because you don't know at compile
>time which one will be called (the actual address is looked up at run time
>in the v-table). If you know the method that will be called the compiler
can
>decide to inline it (i.e. copy the assemble code rather than doing a full
>call). The final keyword mark the method as not being polimorphic which
>makes it a candidate to be inlined (the drawback is that you cannot
overload
>it anymore).

Ah. Ok, I'll go with that one.

<snip stuff about recordsets>

<snip stuff about lostfocus>

>Yes but I don't know how they did it.

UserControls are always running, even in the IDE. My guess is you might
have to subclass the mouse messages, but I don't think doing a tabbed
control would be too difficult (well, aside from drawing and laying out the
tabs).

>If you create a splitpanel you could want to resize added controls at
design
>time.

That'd be an interesting weekend experiment.

<snip stuff>


>Crash the IDE all the time. Especially when debugging.

That's a problem with the IDE, not with XTimers, and goes back to re-entrant
callbacks and multithreading, I'm afraid. This shouldn't happen, though, if
you have XTimers as a DLL, and you don't do silly things (like use 'End')

>An abstract method is close to a typed function pointer. You just declare
>the signature and the name without the implementation. Still it is part of
>the interface so you can write code that call it. It is the responsibility
>of the subclasses to provide the actual implementation by overloading the
>function.

I guess I'm just lost on how that differs from just using an interface?

>I was not very clear about this one. What I want is to be able to call
>methods on an interface without having to get through another typed object
>like that
>
> dim o As MyClass 'My class implements MyInterface
> o.AmethodOnMyClass
> o.AmethodeOnMyInterface

I think this would involve _serious_ problems if you have two interfaces
that both have a method with the same signature. Ie, if I have CAnimal that
Implements IDog and Implements ICat, and both interfaces have the "Eat"
method. A better solution would be if VB supported casting, I think.

>I am afraid you are right about this one. But I cannot understand how
>someone could ever dream of witting code without declaring it variables.
>(Apart form scripting)

Goes back to the old QuickBasic, I'm afraid.

>True you can write procedural code with object oriented languages (which is
>something you should avoid) but it is more difficult because it goes
against
>the philosophy of the language. Putting a static method in class is better
>if
>it is related to the class so everything is in one place (try to implement
>the singleton pattern (a class that can be created only once) in VB and
>compare it with solution using static method in the class). What's more I
>think that a language should forbid you to do dangerous constructions (such
>as not declaring variables). I know that many programmers will disagree
with
>me on that saying you just have to use it the right way. The problem if you
>leave standard module in VB is that most people will never use objects and
>go on writing procedural code forever. Of course I don't think it will ever
>happen. What's more, from time to time, if you want to improve you have to
>break up backward compatibility and get rid of the mistakes of the past.
>Best
>example: Java. Strangely it is providing more or less the same
>functionalities (more for now) than VB (I am speaking about the language)
>but it is far more structured and is easier to learn (and VB is supposed
to
>be basic).

I like OO programming...but I also like the convenience of a BAS module. I
can stick my public app-wide variables in there, or some common functions
that aren't really linked to objects, and be done with it. I can do the
same thing in OO with static objects and static methods, so I was being
quite honest when I said I didn't really see a difference. Removing BAS
modules and making programmers write 'static' in front of things wouldn't
solve the problem of bad code, IMHO.

>It will really help with (Windows) subclassing.

The problem with it is that Windows expects a function pointer to be a
32-bit address. But a function pointer on an object needs 64 bits; 32 bits
to hold the pointer to the function, and 32 bits to hold the pointer to the
object's data. Ergo, the problem. I've heard that COM+ resolves this
(perhaps by recognizing class function pointers as distinct from function
pointers and being able to translate them in both directions), but no hard
facts.

<snip stuff on Extender>

>What do you mean by IIRC?

If I Recall Correctly

>Ok you could need not to implement events (event if I don't know why) but
>not being able to implement them when you need it is breaking the interface
>contract.

Isn't the whole point of an event that you may or may not need to implement
it? If it's required, I usually find a callback interface to be better.

<snipped QuickBasic horrors>
>To be honest I have never been able to be used to calling sub without
>parenthesis. That's why it is bothering me so much.

I honestly don't see why VB doesn't just let you.

>Why to start arrays at 0 and collections at 1? What's more when you are
>using components from time to time their collections start at 1 and
>otherwise they start at 0. If I remember right the VB Forms collection
>starts
>at 0.

Ah, but I don't think that the Forms collection started out as a collection
(if it even is one). I think it was originally an array, and then just got
some methods tacked onto it. Ditto with the controls collection.

>In French it is called "présentation de feuille" (don't know how to call
it
>in English). It is this useless thing which allows you to decide where your
>forms will appear at start up.

Oh, yeah. I take three seconds when I start programming on a new machine
(or with a new installation of VB) to get rid of it once and forever.

>Oops don't misunderstand me we need the addressOf for callback but that's
>all I am ready to accept from pointers. I am just a bit afraid because
every
>now and then you find someone asking for string pointers, or wanting to go
>around Com reference count to avoid circular references (you can use a
>wrapper for that). Pointers and memory management are alright for low level
>languages or when your primary concern is about performance but it adds a
>lot
>of work and a lot of stupid and difficult to find bugs. So I would rather
>keep then off VB.

I'd prefer to keep them in VB. When I use them, I wrap them, so I don't
need to deal with them a lot, but I'd hate to have to dredge up a C++ DLL
everytime I wanted to create a weak reference to something.

>Laurent Opprecht


--
Colin McGuigan

[yamin]

"Laurent Opprecht" <laurentopprecht@lga.ch> wrote:
>Here is a small problem: I would like to be able discover an object
>interface at run time. Number of functions, function names, signatures etc..
>For that I need to use IDispatch and I am a bit lost. The idea is to create
>the implementation/delegation wizard myself. If you have a solution it is
>welcome.
>> Colin McGuigan
>Laurent Opprecht

You already can!
just add a reference to TypeLib Information - (something like C:\winnt\system32\tlbinf32.dll)
Also, search the MSDN with the keyword "tlbinf32". You will find several
articles explaining how to use this library
Yamin

[Laurent Opprecht]

Thank you very much Yamin.

Laurent Opprecht

yamin <yaminmuyal@hotmail.com> wrote in message
news:3923f0fa$1@news.devx.com...
>
> "Laurent Opprecht" <laurentopprecht@lga.ch> wrote:
> >Here is a small problem: I would like to be able discover an object
> >interface at run time. Number of functions, function names, signatures
etc..
> >For that I need to use IDispatch and I am a bit lost. The idea is to
create
> >the implementation/delegation wizard myself. If you have a solution it is
> >welcome.
> >> Colin McGuigan
> >Laurent Opprecht
>
> You already can!
> just add a reference to TypeLib Information - (something like
C:\winnt\system32\tlbinf32.dll)
> Also, search the MSDN with the keyword "tlbinf32". You will find several
> articles explaining how to use this library
> Yamin
>