Anyone want to lay odds that their insurance company is looking for a loophole in the "hole-in-one" policy so they don't have to pay out?

My Blog [^]

The spam is being manually entered or copy/pasted. While this would stop an automated comment spammer, it wouldn't stop our current moron.

At work, we've started battling a comment spammer. (Details here.) Needless to say, it's been fun. :mad: Now, I hate comment spam with a passion I normally reserve for Nazi's and various fruits, but I'm in a bit of a pickle. As a government entity, we have to ensure that no legitimate citizen feedback is ignored or dropped or not read in a timely fashion, so automated spam filtering techniques aren't going to work. We don't want to use CAPTCHA images on our feedback page due to accessibility concerns. (We have some active visually-impaired and hearing-impaired citizens in our community, so we can't even reliably use the Speech SDK to talk to a .WAV and play it out for people.) I've been thinking of implementing a delayed entry system as a means of stopping the spam. Essentially, I'd cache the comment, and spin-refresh on a page depending on the number of "spam" triggers I detect in the comment. The comment wouldn't be committed unless they stuck around for the save to complete. For most spammers, time is a critical element. Most would jump ship fairly quickly, rather than wait for up to a minute for their comment to save. Plus, if I saved the "non-saved" messages for analysis, I could further refine the spam filter. Any thoughts on this one? Does this idea have any merit?

There are tons of ways. Pretty much all of them require a second executable. Here is the source used for updating programs on our Intranet. There is update detection code in each executable. When that executable detects that there are updates available, it notifies the user. When the user says "Update," the program launches the updater and closes. This isn't the cleanest or most secure code, but it works.

Imports System.IO
Imports System.Net

Public Class frmMain
    Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

    Public Sub New()
        MyBase.New()

        'This call is required by the Windows Form Designer.
        InitializeComponent()

        'Add any initialization after the InitializeComponent() call

    End Sub

    'Form overrides dispose to clean up the component list.
    Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
        If disposing Then
            If Not (components Is Nothing) Then
                components.Dispose()
            End If
        End If
        MyBase.Dispose(disposing)
    End Sub

    'Required by the Windows Form Designer
    Private components As System.ComponentModel.IContainer

    'NOTE: The following procedure is required by the Windows Form Designer
    'It can be modified using the Windows Form Designer.  
    'Do not modify it using the code editor.
    Friend WithEvents Button1 As System.Windows.Forms.Button
    Friend WithEvents RichTextBox1 As System.Windows.Forms.RichTextBox
    Friend WithEvents ProgressBar1 As System.Windows.Forms.ProgressBar
     Private Sub InitializeComponent()
        Dim resources As System.Resources.ResourceManager = New System.Resources.ResourceManager(GetType(frmMain))
        Me.Button1 = New System.Windows.Forms.Button
        Me.RichTextBox1 = New System.Windows.Forms.RichTextBox
        Me.ProgressBar1 = New System.Windows.Forms.ProgressBar
        Me.SuspendLayout()
        '
        'Button1
        '
        Me.Button1.Enabled = False
        Me.Button1.FlatStyle = System.Windows.Forms.FlatStyle.System
        Me.Button1.Location = New System.Drawing.Point(360, 8)
        Me.Button1.Name = "Button1"
        Me.Button1.Size = New System.Drawing.Size(72, 32)
        Me.Button1.TabIndex = 2
        Me.Button1.Text = "Launch"
        '
        'RichTextBox1
        '
        Me.RichTextBox1.Location = New System.Drawing.Point(8, 48)
        Me.Ri

That would almost work. We'd need an Application.DoEvents after the newChild.Show because the top/left are not set until the new form is actually visible (very frustrating trying to figure THAT out...), and we'd actually need to check the MdiClient size, not just the ClientSize, or else status bars and what not would not be taken into account. The biggest problem I have with the current solution is that when the form is created, it shows at the original location for 1/60th of a second, and the flicker looks bad.

Is it possible to detect whether or not you are running from an NGEN'ed assembly or not? I ask because as a side-effect of an NGEN experiment, I found that I can NGEN a running application without any problems. Given that my assembly runs a bit faster NGEN'ed than not, I'd like to detect whether or not the .NET Framework has detected that my assembly is no longer NGEN'ed, and if it is not, NGEN it for next time the assembly is launched. While the NGEN executable is able to detect whether or not your assembly has been NGEN'ed and does a quick exit if it has, I don't want to waste the cycles creating the process if I don't have to.

In MDI applications, it is a common occurance for the user to open several different forms. However, even if one form is closed, the "offset" used to place the subsequent forms is remembered, so each form is gradually shifted down and to the right until it shifts partially or fully outside of the MDI client area. I'd like to ensure that the MDI clients are always completely within the MDI client area upon first being opened. I have come up with a hack involving the OnVisibleChanged event and two helper functions (listed below), but is there a more graceful way of doing this?

' In each form
    Protected Overrides Sub OnVisibleChanged(ByVal e As System.EventArgs)
        EnsureInsideMDIArea(Me)
    End Sub

' Helper functions in a module
    Public Function GetMDIClientRect(ByVal frm As Form) As Rectangle
        Dim pr As Rectangle = Rectangle.Empty
        For Each c As Control In frm.Controls
            If TypeOf c Is MdiClient Then pr = c.ClientRectangle
        Next
        Return pr
    End Function

    Public Sub EnsureInsideMDIArea(ByVal frm As Form)
        ' Ignore if not an MDI client
        If Not (frm.MdiParent Is Nothing) Then

            ' Get parent rect
            Dim pr As Rectangle = GetMDIClientRect(frm.MdiParent)

            Dim r, b As Integer
            r = frm.Size.Width + frm.Left
            b = frm.Size.Height + frm.Top

            If r > pr.Right Or b > pr.Bottom Then
                frm.Top = 0
                frm.Left = 0
            End If

        End If
    End Sub

The example was a simplified version of the actual port work. The example has problems after 30,000 entires, as does the actual port work, which has 11 seperate properties, including three delegates. As for your recommendation, I do agree. That would be preferred were it possible. However, there are strengths to using a ReadOnly array, namely compile-time array write checking rather than runtime checking, increased performance, and strong typing without a wrapper class. But the main issue here is which is wrong: the compiler compiling code that should not run, or the CLR crashing on code that should?

One of the features that I really like about Visual Basic .NET is the ability to declare ReadOnly arrays of value types. However, use of this feature can cause Visual Basic .NET to emit an invalid assembly. To demonstrate what I'm talking about, let's construct a simple lookup table. The table in question maps integers to doubles and strings, never changes, and does not have an available formula to allow calculations. Because the LUT needs to be available from launch, a ReadOnly array is created. Public Structure LUTItem Dim D As Double Dim S As String Sub New(DValue As Double, SValue As String) Me.D = DValue Me.S = SValue End Sub End Structure Public ReadOnly LUTS() As LUTItem = { _ New LUTItem(0.03,"A number"), _ New LUTItem(0.91,"Another number" } For small arrays, this works wonderfully. However, when you pass around 30,000 items in your array, two things happen: 1) Visual Studio .NET gets heinously slow after every change to the file as it recompiles the file. 2) When you build, the build is successful, but when you run, you are told that the assembly is not valid. So, my question is this: why is there a disconnect here? If this particular structure is invalid for the runtime, why does it compile without errors or warnings? If this particular structure is valid for the runtime, why does the CLR call it an invalid assembly? Note: I know that creating a massive LUT that way in the assembly is poor coding style. However, when porting software, it is often easier to do a straight port first, then enhance later. I encountered this porting a C++ library to VB.NET when I moved over a 48,000+ element array of structs used in the code that included function pointers and data to pass to the function pointers. Because it was a const array, I was trying to keep a similar access modifier in case any changes I made to the library inadvertently changed values in the array. Besides, who wants to create 48,000+ delegates while loading a file?