PlausiblyDamp

What does your code look like at the moment, and what problem are you having?

some possible ways: Dim moment As Date = Date.Now MessageBox.Show(moment.ToLongTimeString() & " " & moment.ToLongDateString()) 'or MessageBox.Show(moment.ToString("F")) 'or MessageBox.Show(moment.ToString("hh:mm:ss dd/MM/yyyy")) by the way MessageBox.Show is more .Net the the VB6 msgbox function.

stringVar = stringVar.TrimEnd()

straight from msdn private void PopulateInstalledPrintersCombo() { // Add list of installed printers found to the combo box. // The pkInstalledPrinters string will be used to provide the display string. String pkInstalledPrinters; for (int i = 0; i < PrinterSettings.InstalledPrinters.Count; i++){ pkInstalledPrinters = PrinterSettings.InstalledPrinters[i]; comboInstalledPrinters.Items.Add(pkInstalledPrinters); } }

I personally find the second way more readable anyway in one line I can see that a method is being called with a point of x = 3 and y = 6.

the lines VertBuffer = New VertexBuffer(GetType(CustomVertex), NUM_VERTS, m_objDevice, Usage.WriteOnly, FVF_CUSTOMVERTEX, Pool.Default) Verts = VertBuffer.Lock(0, are creating the array at the correct size

What problems are you having - any exceptions thrown etc?

You could cast the sender object to the correct type dim theNode as nodeObject = DirectCast(sender, nodeObject) 'Then this should work dim s as string s= theNode.Code

Is the form main the startup form for the application? If so when you launch the other forms you will need to pass a reference to main. http://www.xtremedotnettalk.com/showthread.php?s=&threadid=75911 http://www.xtremedotnettalk.com/showthread.php?s=&threadid=73538

Have a look at : http://www.xtremedotnettalk.com/showthread.php?s=&threadid=73761&highlight=net%2A+send

Dim m as new main() m.label6.text = textbox1.text In .Net forms are objects like everything else.

Easiest way is read it into either a string or a byte array depending on it's contents and return that to the client. Saving the file to disk (or whatever else) is then the clients problem.

You don't appear to be setting the variable Images to anything. Dim Images As Image What should it contain?

Agreed but he also gives firstly a good way to do splash screens and suggests that forcing a user to sit and stare at a splash screen may be a bad idea, a topic also discussed in the second thread I linked to. Is there a requirement for the 3 second delay? If so you could just change VolteFace's code so instead of filling a listbox it just calls threading.Thread.CurrentThread.Sleep(3000)

Not entirely sure inheritance is entirely the correct solution here. Also if you want to learn inheritance and OOP ideas in general then a more back to basics approach may be in order. not .Net but worth a look : http://www.quiver.freeserve.co.uk/OOP1.htm same again but also worth a look http://homepages.unl.ac.uk/~chalkp/proj/ootutor/oopconcepts.html

http://www.xtremedotnettalk.com/showthread.php?s=&threadid=77706&highlight=splash+screen Thank VolteFace for the above. also http://www.xtremedotnettalk.com/showthread.php?s=&threadid=76337&highlight=splash+screen may be worth a read

http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B193366 gives a link where the .CAB file for the control can be downloaded from, inside you should find the .OCX control (about 1M in size though). This can be deployed to the client and then registered with regsvr32 - or alternatively create a setup project in VS.Net and include the OCX in your package.

If you already have Framework version 1.1 installed then it should work, no need to remove it. If you go through the setup it prompts you to insert the update disc, what happens after that? Do the error logs contain any information?

http://msdn.microsoft.com/vstudio/productinfo/sysreqs/default.aspx

In the changed event you could use simply use TextBox1.Text = TextBox1.Text.ToUpper

The server will require the .asmx files, the web.config and the bin directory with the dll error in it. Also the folder the web service resides in needs to be configured as a virtual directory under IIS. The server will also require the .Net framework installed on it.

Personally I avoid the VB6 functions because I work with both VB and C# so I find it easier to work with just one set of commands. Commands like CInt do call into the VisualBasic Dlls so there is probably an associated performance hit.

Does the destination PC also have this control installed? If not it will need to be installed and registered before your app will work.

ildasm.exe to view the code. and another update though.... If you are using an object with a property that returns a string things do change...... Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim y As New Test Dim z As String z = "yyy" y.Testing &= z End Sub Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click Dim x As Test Dim z As String z = "xxx" x.Testing = x.Testing & z End Sub End Class Public Class Test Private x As String Public Property Testing() As String Get Return x End Get Set(ByVal Value As String) x = Value End Set End Property End Class The x.Testing = x.Testing & z way produces the following MSIL .method private instance void Button2_Click(object sender, class [mscorlib]System.EventArgs e) cil managed { // Code size 31 (0x1f) .maxstack 3 .locals init (class WindowsApplication2.Test V_0, string V_1) IL_0000: newobj instance void WindowsApplication2.Test::.ctor() IL_0005: stloc.0 IL_0006: ldstr "xxx" IL_000b: stloc.1 IL_000c: ldloc.0 IL_000d: ldloc.0 IL_000e: callvirt instance string WindowsApplication2.Test::get_Testing() IL_0013: ldloc.1 IL_0014: call string [mscorlib]System.String::Concat(string, string) IL_0019: callvirt instance void WindowsApplication2.Test::set_Testing(string) IL_001e: ret } // end of method Form1::Button2_Click while the y.Testing &= z method gives .method private instance void Button1_Click(object sender, class [mscorlib]System.EventArgs e) cil managed { // Code size 33 (0x21) .maxstack 3 .locals init (class WindowsApplication2.Test V_0, string V_1, class WindowsApplication2.Test V_2) IL_0000: newobj instance void WindowsApplication2.Test::.ctor() IL_0005: stloc.0 IL_0006: ldstr "yyy" IL_000b: stloc.1 IL_000c: ldloc.0 IL_000d: stloc.2 IL_000e: ldloc.2 IL_000f: ldloc.2 IL_0010: callvirt instance string WindowsApplication2.Test::get_Testing() IL_0015: ldloc.1 IL_0016: call string [mscorlib]System.String::Concat(string, string) IL_001b: callvirt instance void WindowsApplication2.Test::set_Testing(string) IL_0020: ret } // end of method Form1::Button1_Click which is slightly different. Not too sure how much difference this would make in performance though. Also this MSIL will get JIT compiled on a run anyway so there may not be an awful lot of difference in this case. More complex objects or more complex Get / Set procedures may be affected though.

Got to disagree with them there. Just created a simple test project Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim y As String y &= "yyy" End Sub Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click Dim x As String x = x & "xxx" End Sub and in both cases the MSIL generated was the same (in fact it didn't really differ between debug and release mode) .method private instance void Button1_Click(object sender, class [mscorlib]System.EventArgs e) cil managed { // Code size 13 (0xd) .maxstack 2 .locals init (string V_0) IL_0000: ldloc.0 IL_0001: ldstr "yyy" IL_0006: call string [mscorlib]System.String::Concat(string, string) IL_000b: stloc.0 IL_000c: ret } // end of method Form1::Button1_Click .method private instance void Button2_Click(object sender, class [mscorlib]System.EventArgs e) cil managed { // Code size 13 (0xd) .maxstack 2 .locals init (string V_0) IL_0000: ldloc.0 IL_0001: ldstr "xxx" IL_0006: call string [mscorlib]System.String::Concat(string, string) IL_000b: stloc.0 IL_000c: ret } // end of method Form1::Button2_Click you will notice that in both cases it calls the String.Concat anyway - which also answers the other thread you posted on strings ;) edit: thought about something else Also just retried it using a string variable rather than a hardcode string and again the two methods produced the same code.