In VB6 you could use the commondialog to show several of the
standard operating system dialogs. For example show the a
the print setup dialog box or the print dialog box.
VB6 Example showing the Print Setup Dialog Box
cdlgprint.Flags = cdlPDPrintSetup
cdlgprint.ShowPrinter
In .NET you have 4 kinds of Priting Dialogs:
PageSetupDialog
PrintDialog
PrintDocument
PrintPreviewDialog
So during a migration remember that if your were using the the CommonDialog.Flags
property to show the PrintSetupDialog you will have to change that for something like
var cdlgprint_ForPrintSetup = new PrintSetupDialog();
cdlgprint_ForPrintSetup.Print()
When you are migrating from VB6 to VB.NET most of the Put statements will be migrated to
FileSystem.FilePutObject http://msdn.microsoft.com/en-us/library/z07he9as.aspx
The problem with this is that if you need that the files generated by your application to be compatible byte per byte
with your VB6 generated files you must put special attention.
Take a look at this example:
Module Module1
Sub Main()
Dim str = "TEXTDATA"
FileSystem.FileOpen(1, "c:\temp\file1.dat", OpenMode.Random, OpenAccess.Write, , 30)
FileSystem.FilePutObject(1, str, 2)
FileSystem.FileClose(1)
End Sub
End Module
Module Module1
Sub Main()
Dim str = "TEXTDATA TEXTDATA TEXTDATA"
FileSystem.FileOpen(1, "c:\temp\file1.dat", OpenMode.Random, OpenAccess.Write, , 30)
FileSystem.FilePut(1, str, 2)
FileSystem.FileClose(1)
End Sub
End Module
The difference might seem minimal but it can be hard to detect.
The different byte is caused by using the FilePutObject instead of FilePut method
Today I was writting a custom control which had a custom property whose type was an EnumType.
I needed the DefaultVAlue attribute so Visual Studio.NET will not serialize the value to the container's code.
Usually in C# you can do something like:
[DefaultValue(TheEnum.TheValue)]
public TheEnum MyProperty
{
get { ... }
set { ... }
}
And that works. Well it does not work in VB.NET
To use an enum value for an Enumeration type in VB.NET you should write something like:
<DefaultValue(GetType(TheEnum), "TheValue")> _
Property MyProperty as TheEnum
Get
...
End Get
Set
...
End Set
End Property
VB6 Migration, HTML5 Forms and ASP.NET Web Forms
If you come from a VB6 background, and your application is still in VB6,
you are probably wondering that this might be a good time to move out of VB6.
But is also a complex time. Which is right path: WinForms, Silverlight, WPF, HTML5?
Choosing the right target platform can be very tricky and depends on many varaiables.
So let's assume in this post that you have already decided that you want to use Web Tecnologies
and why not HTML5 as well.
ASP.NET Web Forms is a good technologie and developing forms with it is also very easy,
but can you develop HTML5 applications with this?
Well Brandon Satrom has a nice column in MSDN Magazine about Web Forms with HTML5 Forms.
He says:
If you’re planning to do HTML5 Forms development with ASP.NET Web Forms, there’s good news:
Many HTML5-related updates to .NET and Visual Studio are being released out-of-band, so you
don’t have to wait for the next framework version to use these features today.
To get started with HTML5 Forms and ASP.NET Web Forms, you’ll need to grab a couple of updates.
First, make sure you have Visual Studio 2010 SP1 (bit.ly/nQzsld).
In addition to adding support for new HTML5 input types and attributes, the service pack also
provides some updates that enable you to use the new HTML5 input types on the TextBox server control.
Without this update, you’d see compile-time errors when using the new types.
You’ll also want to grab the Microsoft .NET Framework 4 Reliability Update 1 (bit.ly/qOG7Ni).
This update is designed to fix a handful of problems related to using the new HTML5 input types
with ASP.NET Web Forms. Scott Hunter covers a few of those—UpdatePanel, Validation Controls
and Callbacks—in a blog post from early August that you can check out at bit.ly/qE7jLz.
Update:
Mobilize.NET and Artinsoft.com company now helps in the HTML5 migration problem from VB6, Windows Forms and PowerBuilder. http://mobilize.net/default.aspx
VB6 Application where STAThread. And that is the reason that Winforms applications are
by default STAThread. Using MTAThread causes problems with some ActiveX Controls.
However STAThread has a nasty implication
see: http://social.msdn.microsoft.com/Forums/en/clr/thread/835db88e-db51-4f83-bd4f-a10d126effa6
"inside a STA thread, the finalizer thread must reenter the STA thread in order to finalize the component.
If the STA is blocked and isn't pumping, the finalizer has to wait in line until it does"
This can then cause leaks of components affecting the memory use.
"To get around this issue, you have some options (from best to worst), e.g.:"
1) Create your components in an MTA. ... Unless you have an explicit reason to use an STA, you shouldn't. I realize that Visual Studio adds these to some entrypoints automatically for you.
For example, most GUI applications have to start life inside an STA, e.g. WinForms, but Console applications" or services "certainly do not."
"2) Deterministically release your resources. If you are using components which implement IDisposable, wrap them in
a C# 'using' statement or call Dispose() on them explicitly when you're done.
RCW's done have Dispose on them. You can consider doing a Marshal.ReleaseComObject on them directly,
but realize that this can cause problems if you're not really done using the COM object."
"3) Use another form of blocking to prevent the primary thread from exiting."
"Chris Brumme writes about this" (COM Apartments)
" at http://blogs.msdn.com/cbrumme/archive/2004/02/02/66219.aspx; caution: that's a fairly lengthy post"
If during a VB6 migration you decide o take a step forward and move your databases to MS SQL
don't worry. The SQL Server team has a tool just for that.
I just don't know why it is so hard to find it in google. But the appropiate link is:
http://blogs.msdn.com/b/ssma/p/access.aspx
Also a recent article in Teched goes into all the gory details: http://technet.microsoft.com/en-us/magazine/hh334645.aspx
Good Luck and don't hesitate to contact us for any doubts.
Finding DataReaders that are not being close in an .NET application can be something difficult.
Thats why I use this trick to detect which DataReaders where not close.
1. First add a new code file to your project.
2. Enter this code:
public static class SqlReaderTracer
{
static Dictionary<WeakReference,System.Diagnostics.StackTrace> traceInfo = new Dictionary<WeakReference,System.Diagnostics.StackTrace>();
public static System.Data.SqlClient.SqlDataReader ExecuteReaderEx(this System.Data.SqlClient.SqlCommand command)
{
var stack = new System.Diagnostics.StackTrace(1, true);
var reader = command.ExecuteReader();
traceInfo.Add(new WeakReference(reader), stack);
return reader;
}
public static void PrintTraceState()
{
Console.WriteLine("*******SQL Trace Results************");
foreach (var reader in traceInfo.Keys)
{
if (reader.IsAlive)
{
var traceInfoFrame = traceInfo[reader].GetFrame(0);
var methodWhereItWasCreated =traceInfoFrame.GetMethod().DeclaringType.FullName + "." + traceInfoFrame.GetMethod();
Console.Write("Reader alive created in " + methodWhereItWasCreated);
if (traceInfoFrame.GetFileName() != null)
{
Console.Write(string.Format("at {0} ({1},{2})",traceInfoFrame.GetFileName(),traceInfoFrame.GetFileLineNumber(),traceInfoFrame.GetFileColumnNumber()));
}
Console.WriteLine();
}
}
}
}
And then to a Find /Replace All and change all the .ExecuteReader() for .ExecuteReaderEx(). 3. Ok Now. You are all set. To test it do something like this:
class Program
{
static void Main(string[] args)
{
var xxx = new System.Data.SqlClient.SqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=D:\MyProjects\Phonebook.mdf;Integrated Security=True");
xxx.Open();
var ccc = xxx.CreateCommand();
ccc.CommandText = "SELECT * from Phonebook";
var reader = ccc.ExecuteReaderEx();
xxx.Close();
SqlReaderTracer.PrintTraceState();
return;
}
}
And you will see an output like:
Today my friend Allan was asking me if I know of a way to save msbuild output as an XML file. His idea was to be able to process compilation errors without depending on tools like grep / sed. I really had never done that so I ask him to send me a link if he found something.
Well he found http://geekswithblogs.net/kobush/articles/xmllogger.aspx
He tested it and he says it works great. So if you ever need something like that take a look at it.
In VB.NET if you want to make your interfaces available thru COM and make sure that its parameters are of a certain type you have to use the MarshalAs attribute. For the return type it is a little tricky because it has to be added after the As Keyword.
<ComVisible(True)> _
<Guid("15D492C7-CD14-4239-B98D-689F329EEDA4")>
<InterfaceType(ComInterfaceType.InterfaceIsDual)> _
Public Interface MyCOMInterface
Function FooReturningShort(ByVal data As Integer, <MarshalAs(UnmanagedType.U2)> ByVal shortData As short) As <MarshalAsAttribute(UnmanagedType.U2)> Short
End Interface
If you used the Graphics32 library for Delphi in the past and you try to use it in delphi xe you will find several compilation errros.
Downloads from sourceforge have not been updated but you can download the .tar.gz file from http://graphics32.svn.sourceforge.net/
And the open the GR32_RSXE1.dpk