Pas regardé en détails encore, 1 petit hic pour le rendu graphique tout de même

* Essaye de faire un rendu en XAML pour ton pendu t'as déjà des outils de drawing integré
Je pense que ca te fera monter en compétence sur une techno qui est utilisé de plus en plus partout, windows phone, page web (Silverlight), etc ...
* Si tu reste en WinForm, essaye de faire un rendu avec GDI(GDI+) que tu trouvera dans System.Drawing (reference System.Drawing.dll) qui te permet de faire du dessin propre :
Cercle, Ellipse, Ligne, Couleur etc .....

Sinon il te reste l'option Direct2D, mais qui demande des DllIport, et est compatible avec les OS actuel, donc pas de compatibilité avec les OS de plus de 10 ans (XP, 2003, 2000)

Désolé pour la correction automatique du téléphone...
Pour en revenir a ton Code
Ce n'est pas une site ou on jete 10 lignes de code ... On attend plutôt un vrai projet, des explication, justification, choix technique

Au passage voir un Array de formulaire est pour le moins improbable dans n'importe quel projet propre. En général en winform le pattern que tu utilises, bien souvent MVC, fait que tu ne regroupe pas tes objet de la sorte.

L'array n'est jamais vidé ...

Etc.

Je vois que ton Code répond directement a un événement de la couche ui sans aucune remontée ou test en couche métier ...

for i=1 to n-1

Y a rien qui te choques ?
Ou t'as oublié "Option Binary" et tu oublis le premier form
Ou alors tu va publier le dernier form
Ou alors tu n'a fait exprès mais vu que tu ne fait aucun test d'intégrité sur ton Close c'est de la roulette russe

Code a supprimé en demandant dr le placer sur le site adaptez : c'est un snippet pas une source ...
Le Code inclus pas Mal de bas practices et anti pattern
A éviter pour pas Mal de raison ...

Les scheduler sont a implémenté c'est juste une notion obligatoire, y a rien de magique et tout fait, c'est spécifique a ton code

Que penses tu d'implémenter un Scheduler plutôt ?
De ne pas utiliser de "Timer" Winform mais plutôt un timer du namespace System.Threading, ou mieux encore les ReactivesExtensions qui fournisse une batterie d'objet basé sur le temps justement.
Je pense qu'il est imperatif que ton TimeLine, ou du moins le Scheduling s'effectue dans un autre thread avec une priorité moindre.
les évènements doivent eux être invoqué dans le Contexte dans lequel ils ont été créé, ou bien dans un nouveau thread/context. Pour cela utilise les classes : Task, SynchronizationContext, Dispatcher, ThreadPool, etc ...

pour tes Events tu écris (mon vb.net est rouillé ca fait quelque année que je suis passé au C# sans avoir eu l'occasion/l'envis de retouché au vb):
Public Delegate Sub EventTickEventHandler(ByVal EventString As String)
Public Event EventTick As EventTickEventHandler

tu devrais préférer :
Public Event EventTick As EventHandler(Of EventTickEventArgs)
public class EventTickEventArgs inherits EventArgs
    public sub new (eventString as String)
        EventString = eventString
    end sub

    public property EventString as String
End Class
bien que j'ai l'impression que tu puisse directement passé le reference de l'event dans l'args plutot que juste la string
Cela te permettrai de respecté le modèle des évènements utilisé partout dans le runtime .net

Sur CodeProject tu peux trouvé une librarire orienté Temps justement avec pas mal de fonctionnalité dedans si tu veux y jeter un oeil

j'en reviens a la nature du problème hein plutot que des client et ERP :
Evaluer une expression mathématique

en reponse tu propose un Compute d'une ...DataTable

Y a rien qui te choc ?

...
no comment la

Je pense qu'effectivement y a bien une 10aine de moyen comme aserf le montre de faire du code rapidement mais de manière pour le moins HORRIBLE, tant le code n'as pas été designer pour cela, ou bien ne serais ce qu'en terme de perf ou mémoire ...
A force de pas vouloir faire d'effort ou de gagner du temps ...
Enfin bon il parait que je râle trop mais la on atteint des sommets

illegal ?

y a pas de built-in existant, il faut que tu l'écrive a la main, ça correspondrait a un fichier de settings qui permettrai d'enrichir les donnée parsé / parsable autant a la reconnaissance qu'a l'exécution.
en définissant un bon schéma xslt, ca te permettrai de gerer une liste des opérateur reconnu, le nombre d'opérande, leur type, leur taille, leur syntaxe, etc ...
Tu peux même gérer ça via MEF (Managed Extensibility Framework, .net 4.0 (ou 3.5 si tu recup via codeplex)), cela permettrai d'importer des assembly avec les codes des parser / executeur à chaud de manière a permettre a un utilisateur lambda de rajouter sa propre bibliothèque de fonction

Le fichier "Help.txt" n'est d'aucune aide ....
a part des "?????????????????????????" dedans y a rien (du moins via la visionneuse du site
Merci de le mettre a jour pour toute personne intéressée

Quant au code ...
Mono Bloc
Tout dans un fichier
tout dans une classe
tout dans le code UI, dans le form en plus
Un enorme switch case avec les caractère codé en dur plutot qu'un mapping via un fichier XML char <=> func + param & operand

Private Sub mathexpressiontext_KeyUp(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs) Handles mathexpressiontext.KeyUp
    If TypeOf (sender) Is TextBox Then
        If DirectCast(sender, TextBox).Text <> String.Empty Then
            evaluer.Enabled = True
        Else
            evaluer.Enabled = False
        End If
    End If
End Sub

....

fonction private => appeler que par ton form donc t'as la maitrise de l'appelant qui en explorant ton code est forcement une textbox, pourquoi faire un "if (type is ...)" ????
ta fonction aurait un scope public ou alors tu code modulaire ... pourquoi pas mais la ... non
Sinon en une ligne ...
evaluer.Enabled = String.IsNullOrEmpty(TaTextBox.Text)



J'ai arrêter la lecture rapidement / pas testé
Code non modulaire ni réutilisable à première vue