Click to See Complete Forum and Search --> : Wish for VB7


mikemontana
03-13-2000, 02:03 AM
1) Ability to send TRACE messages to an OLE logging facility that will work
in both anonymous signons (ie an IIS DLL) as well as an authenticated signon
(ie standard VB desktop app)

2) Ability to natively edit RES files

3) TRY..CATCH..FINALY error trapping - the ON ERROR stuff is nasty

4) Ability to query interfaces at runtime - closer integration to the OLE
IQueryInterface stuff.

5) Ability to write multi-threaded apps (why not its a "Wish List" anyway!)

6) Better integration with MTS - so that VB components can be pooled

7) Runtime introspection - much like the Java Introspection. I want to be
able to determine at runtime what function I'm in, and programatically determine
what methods are available to me.

8) Clean up of the tri-states - NULL, EMPTY, NOTHING etc - while I understand
the meaning of the seperate states they frustrate me when testing for values
of variables. I would like the three to be programatically the same so that
a test for NULL is equiv as a test for EMPTY.

9) Better run-time dependency determining for distributions. The current
DeployWizard in VB6 is really really good. Needs a little polish.

10) Ability to write a VB service directly. (Its a wish list afterall)

11) Ability to pass values into a constructor/class_initialize event.

12) Continued support for the VB Editor extensibility - what a great job
they did with VB6's extensibility.

13) Better string handling algorithms. Right now every time I want to append
a string to a string a whole new string is allocated, teh prev copied + new
string, and the old one is freed. What a dog - especially when building lots
of HTML in a VB IIS DLL. MFC's string class has the ability to pre-allocate
a buffer size - and then auto-trim it when you're done with it. This is what
I'd like.

14) A better method of handling cross project compile dependencies. I go
looney when I have one DLL thats shared by 3 other apps and when i make a
daily build of code the CLSID gets changed and the dependent apps no longer
compile. Try making sense of the three Project Compatibility modes. I dont
have this problem with VC++.

15) A GUID as a native data-type. We all know that a GUID is sorta like a
string, and sorta not. Sorta.

16) Improved #IF...#END IF support. I use this alot and its still pretty
primitive vs. C++ - expansion of the preprocessor would be great. For example
I'd like to be able to declare a whole set of functions as a conditional
compile like:

#IF DEBUG_MODE THEN
Public Sub DEBUG_DoSomething()
...
End Sub

Public Sub DEBUG_DoSomethingElse()
...
End Sub
#END IF

17) Ability to programmatically determine if the app is in Debug/Environment
Mode or in Compile mode (part of introspection I guess).

18) PLEASE RETURN MSDN to a standard-windows format! ooooh i really dislike
the HTML versions... but, admittedly, they are getting better as HTML improves.

19) An improved Collection/Dictionary object. Gee, I'd really like to be
able to programmatically determine if a collection contains an item without
iterating thru the whole thing, or by using nasty ON..ERROR stuff.

20) A nice way to have IIS "shake loose" a VB DLL without having to START/STOP
the Web publishing service. RIght now if you execute a VB-DLL thru an ASP
page the DLL gets "stuck" in memory until IIS is shut down. That hurts.

Alan Gillott
03-13-2000, 10:26 AM
Don't forget to send these to vbWish@microsoft.com. Please remove the stuff
you can do now or has been announced. Or at least reinforce it. eg. Try
catch finally or #If wrapping of procedures that works now: you just ave to
be aware of the real sequence of the file.

mikemontana <mikemontana@hotmail.com> wrote in message
news:38cc84af$1@news.devx.com...
>
> 1) Ability to send TRACE messages to an OLE logging facility that will
work
> in both anonymous signons (ie an IIS DLL) as well as an authenticated
signon
> (ie standard VB desktop app)
>
> 2) Ability to natively edit RES files
>
> 3) TRY..CATCH..FINALY error trapping - the ON ERROR stuff is nasty
>
> 4) Ability to query interfaces at runtime - closer integration to the OLE
> IQueryInterface stuff.
>
> 5) Ability to write multi-threaded apps (why not its a "Wish List"
anyway!)
>
> 6) Better integration with MTS - so that VB components can be pooled
>
> 7) Runtime introspection - much like the Java Introspection. I want to be
> able to determine at runtime what function I'm in, and programatically
determine
> what methods are available to me.
>
> 8) Clean up of the tri-states - NULL, EMPTY, NOTHING etc - while I
understand
> the meaning of the seperate states they frustrate me when testing for
values
> of variables. I would like the three to be programatically the same so
that
> a test for NULL is equiv as a test for EMPTY.
>
> 9) Better run-time dependency determining for distributions. The current
> DeployWizard in VB6 is really really good. Needs a little polish.
>
> 10) Ability to write a VB service directly. (Its a wish list afterall)
>
> 11) Ability to pass values into a constructor/class_initialize event.
>
> 12) Continued support for the VB Editor extensibility - what a great job
> they did with VB6's extensibility.
>
> 13) Better string handling algorithms. Right now every time I want to
append
> a string to a string a whole new string is allocated, teh prev copied +
new
> string, and the old one is freed. What a dog - especially when building
lots
> of HTML in a VB IIS DLL. MFC's string class has the ability to
pre-allocate
> a buffer size - and then auto-trim it when you're done with it. This is
what
> I'd like.
>
> 14) A better method of handling cross project compile dependencies. I go
> looney when I have one DLL thats shared by 3 other apps and when i make a
> daily build of code the CLSID gets changed and the dependent apps no
longer
> compile. Try making sense of the three Project Compatibility modes. I dont
> have this problem with VC++.
>
> 15) A GUID as a native data-type. We all know that a GUID is sorta like a
> string, and sorta not. Sorta.
>
> 16) Improved #IF...#END IF support. I use this alot and its still pretty
> primitive vs. C++ - expansion of the preprocessor would be great. For
example
> I'd like to be able to declare a whole set of functions as a conditional
> compile like:
>
> #IF DEBUG_MODE THEN
> Public Sub DEBUG_DoSomething()
> ...
> End Sub
>
> Public Sub DEBUG_DoSomethingElse()
> ...
> End Sub
> #END IF
>
> 17) Ability to programmatically determine if the app is in
Debug/Environment
> Mode or in Compile mode (part of introspection I guess).
>
> 18) PLEASE RETURN MSDN to a standard-windows format! ooooh i really
dislike
> the HTML versions... but, admittedly, they are getting better as HTML
improves.
>
> 19) An improved Collection/Dictionary object. Gee, I'd really like to be
> able to programmatically determine if a collection contains an item
without
> iterating thru the whole thing, or by using nasty ON..ERROR stuff.
>
> 20) A nice way to have IIS "shake loose" a VB DLL without having to
START/STOP
> the Web publishing service. RIght now if you execute a VB-DLL thru an ASP
> page the DLL gets "stuck" in memory until IIS is shut down. That hurts.

Al Meadows
03-14-2000, 09:57 AM
>>3) TRY..CATCH..FINALY error trapping - the ON ERROR stuff is nasty

Can someone give me an example of how this syntax works? I am especially
interested to see how someone would code for errors that you had not
anticipated.

Miha Markic
03-14-2000, 11:32 AM
So it is in Delphi:

obj := TSomeObject.Create;
try
obj.DoSomething
finally
obj.Free; // obj is always released
end;

try
obj.DoSomething
except
on e: Exception do
ShowMessage (e.Message) // Exception is the base class for
all exceptions
end;

you could also use
try
except
on e: NewExceptiond do ...
on e: MathException do ...
else
DoSomethingElse
end;

and so on. It is a much more powerful and easy to use than On Error.

Miha

"Al Meadows" <fineware@fineware.com> wrote in message
news:38ce4342$3@news.devx.com...
> >>3) TRY..CATCH..FINALY error trapping - the ON ERROR stuff is nasty
>
> Can someone give me an example of how this syntax works? I am especially
> interested to see how someone would code for errors that you had not
> anticipated.
>
>

Al Meadows
03-14-2000, 10:05 PM
The explanation doesn't really help.

Here is a sample VB procedure. Please show me how this would be changed to
support the new Syntax.


Sub PrintIcons()
Dim r As Long
Dim i As Long
Dim X As Long, Y As Long
Dim ThisForm$
ThisForm$ = Me.Name & ":PrintIcons"
On Error GoTo PrintIconError
r = GetIcons
Printer.Scale
For i = 1 To r
Printer.PaintPicture An_Icon(i - 1).Picture, X, Y
X = X + 500
If X + 500 >= Printer.ScaleWidth Then
X = 0
Y = Y + 500
If Y + 500 >= Printer.ScaleHeight Then
Y = 0
Printer.NewPage
End If
End If
Next i
PrinterEnd:
Printer.EndDoc
Exit Sub
PrintIconError:
msgbox Err.Description & "-" & Format$(Err.Number, "0") & "=" &
Format$(i, "0")
Resume PrinterEnd
End Sub

Miha Markic
03-15-2000, 04:00 AM
No problem:

> Sub PrintIcons()
> Dim r As Long
> Dim i As Long
> Dim X As Long, Y As Long
> Dim ThisForm$
> ThisForm$ = Me.Name & ":PrintIcons"

> try 'On Error GoTo PrintIconError

> r = GetIcons
> Printer.Scale
> For i = 1 To r
> Printer.PaintPicture An_Icon(i - 1).Picture, X, Y
> X = X + 500
> If X + 500 >= Printer.ScaleWidth Then
> X = 0
> Y = Y + 500
> If Y + 500 >= Printer.ScaleHeight Then
> Y = 0
> Printer.NewPage
> End If
> End If
> Next i

two posibilities (depends on how the exception is declared)
1. except
on e: Exception do
case e.Number of
PrinterEnd:
Printer.EndDoc
PrintIconError:
begin
msgbox Err.Description & "-" & Format$(Err.Number,
"0") & "=" & Format$(i, "0")
Resume Printer ' this does not exist in
Delphi
end;
end; // case
end;
> End Sub

Here I used standard Exception class.

2. except
on e: EPrinterEnd do
Printer.EndDoc;
on e: EPrintIconError
begin
msgbox Err.Description & "-" & Format$(Err.Number, "0") &
"=" & Format$(i, "0")
Resume Printer ' this does not exist in Delphi
end;
end;
> End Sub

Here are used exceptions that are derived from Exception class (like
EPrinterEnd = class(Exception)). Which means that I can add additional
members to EPrinterEnd. This way exceptions are way more flexible and usable
and readable.

Miha



"Al Meadows" <fineware@fineware.com> wrote in message
news:38ceede4$1@news.devx.com...
> The explanation doesn't really help.
>
> Here is a sample VB procedure. Please show me how this would be changed
to
> support the new Syntax.
>
>
> Sub PrintIcons()
> Dim r As Long
> Dim i As Long
> Dim X As Long, Y As Long
> Dim ThisForm$
> ThisForm$ = Me.Name & ":PrintIcons"
> On Error GoTo PrintIconError
> r = GetIcons
> Printer.Scale
> For i = 1 To r
> Printer.PaintPicture An_Icon(i - 1).Picture, X, Y
> X = X + 500
> If X + 500 >= Printer.ScaleWidth Then
> X = 0
> Y = Y + 500
> If Y + 500 >= Printer.ScaleHeight Then
> Y = 0
> Printer.NewPage
> End If
> End If
> Next i
> PrinterEnd:
> Printer.EndDoc
> Exit Sub
> PrintIconError:
> msgbox Err.Description & "-" & Format$(Err.Number, "0") & "=" &
> Format$(i, "0")
> Resume PrinterEnd
> End Sub
>
>
>

Craig Clearman
03-15-2000, 11:05 AM
Hi Al,

For an example that looks more like what I expect VB to do, and less
like the Pascal example:

Sub PrintIcons()

Dim r As Long
Dim i As Long
Dim X As Long, Y As Long
Dim ThisForm$
ThisForm$ = Me.Name & ":PrintIcons"

Try
r = GetIcons
Printer.Scale
For i = 1 To r
Printer.PaintPicture An_Icon(i - 1).Picture, X, Y
X = X + 500
If X + 500 >= Printer.ScaleWidth Then
X = 0
Y = Y + 500
If Y + 500 >= Printer.ScaleHeight Then
Y = 0
Printer.NewPage
End If
End If
Next i
Catch
MsgBox Err.Description & "-" & Format$(Err.Number, "0") & "="
& Format$(i, "0")
Finally
Printer.EndDoc
End Try

End Sub

Ciao, Craig