Großschreiben ausschalten!

  • VB.NET
  • .NET (FX) 1.0–2.0

Es gibt 23 Antworten in diesem Thema. Der letzte Beitrag () ist von Niko Ortner.

    Großschreiben ausschalten!

    Guten Tag!
    Wie kann ich die Großschreibtaste wieder auf normal schalten?
    Also wenn der User nun das Großschreiben aktiviert hat, soll dies deaktiviert werden!?
    Welche Suchbegriffe kann ich verwenden?
    Ich möchte das die Großschreibtaste wenn aktiviert ist, sich deaktviert.
    by
    Visual Basic.NET 8o
    MS-SQL     8o

    VB.NET-Quellcode

    1. Sub SetCaps(ByVal Status As Boolean)
    2. If Not CBool(GetKeyState(System.Windows.Forms.Keys.CapsLock)) = Status Then
    3. keybd_event(System.Windows.Forms.Keys.CapsLock, 0, 0, 0)
    4. keybd_event(System.Windows.Forms.Keys.CapsLock, 0, KEYEVENTF_KEYUP, 0)
    5. End If
    6. End Sub
    There is no CLOUD - just other people's computers

    Q: Why do JAVA developers wear glasses?
    A: Because they can't C#

    Daily prayer:
    "Dear Lord, grand me the strength not to kill any stupid people today and please grant me the ability to punch them in the face over standard TCP/IP."

    @Schamash
    Vielen Dank.

    Hier die Lösung für alle die das gleiche Problem haben:

    VB.NET-Quellcode

    1. Imports System.Runtime.InteropServices
    2. Public Class Form1
    4. <DllImport("user32.dll", CallingConvention:=CallingConvention.StdCall, _
    5. CharSet:=CharSet.Unicode, EntryPoint:="keybd_event", _
    6. ExactSpelling:=True, SetLastError:=True)> _
    7. Public Shared Function keybd_event(ByVal bVk As Byte, ByVal bScan As Byte, _
    8. ByVal dwFlags As Int32, ByVal dwExtraInfo As Int32) As Boolean
    9. End Function
    10. Public Declare Function GetAsyncKeyState Lib "user32" (ByVal vKey As Long) As Integer
    11. Private Declare Function GetKeyState Lib "user32.dll" (ByVal nVirtKey As Long) As Integer
    13. Sub SetCaps(ByVal Status As Boolean)
    14. If Not CBool(GetKeyState(System.Windows.Forms.Keys.CapsLock)) = Status Then
    15. keybd_event(System.Windows.Forms.Keys.CapsLock, 0, 0, 0)
    16. keybd_event(System.Windows.Forms.Keys.CapsLock, 0, 2, 0)
    17. End If
    18. End Sub
    20. Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
    21. SetCaps(False) ' Hier Werte ändern...!
    22. End Sub
    23. End Class
    Visual Basic.NET 8o
    MS-SQL     8o

    @Cheffboss Deine API-Deklarationen sind falsch (VB6-like). Gugst Du hier.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Richtig, zusätzlich deklarierst Du sie als Integer. Option Strict ON!
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Von hier habe ich den Code für mein kleines Testprogämmchen

    Spoiler anzeigen

    VB.NET-Quellcode

    1. Imports System.Runtime.InteropServices
    3. Public Class frmMain
    5. Private Declare Sub keybd_event Lib "user32" ( _
    6. ByVal bVk As Byte, _
    7. ByVal bScan As Byte, _
    8. ByVal dwFlags As Integer, _
    9. ByVal dwExtraInfo As Integer _
    10. )
    11. Private Const VK_CAPITAL As Integer = &H14
    12. Private Const KEYEVENTF_EXTENDEDKEY As Integer = &H1
    13. Private Const KEYEVENTF_KEYUP As Integer = &H2
    15. Sub SetCaps(ByVal Status As Boolean)
    16. If Status Then
    17. If Not Control.IsKeyLocked(Keys.CapsLock) Then
    18. ToggleCapsLock()
    19. End If
    20. Else
    21. If Control.IsKeyLocked(Keys.CapsLock) Then
    22. ToggleCapsLock()
    23. End If
    24. End If
    25. End Sub
    27. Private Sub ToggleCapsLock()
    28. ' Toggle CapsLock
    30. ' Simulate the Key Press
    31. keybd_event(VK_CAPITAL, &H45, KEYEVENTF_EXTENDEDKEY Or 0, 0)
    33. ' Simulate the Key Release
    34. keybd_event(VK_CAPITAL, &H45, KEYEVENTF_EXTENDEDKEY Or KEYEVENTF_KEYUP, 0)
    35. End Sub
    37. Private Sub btCapsLockOff_Click(sender As Object, e As EventArgs) Handles btCapsLockOff.Click
    38. SetCaps(False)
    39. End Sub
    41. Private Sub btCapsLockOn_Click(sender As Object, e As EventArgs) Handles btCapsLockOn.Click
    42. SetCaps(True)
    43. End Sub
    44. End Class



    Dot.Net 2.0 und ohne Microsoft.VisualBasic Namespace

    @Dksksm Ist trotzdem nicht wirklich .NET, weil (auch) bei Dir die API-Deklarationen veraltet sind. Dafür gibt es DllImport, das entsprechende aus VB6 wäre Declare, was Du hier nutzt.
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    besser?

    Spoiler anzeigen

    VB.NET-Quellcode

    1. Imports System.Runtime.InteropServices
    3. Public Class frmMain
    5. <DllImport("user32.dll", CallingConvention:=CallingConvention.StdCall, _
    6. CharSet:=CharSet.Unicode, EntryPoint:="keybd_event", _
    7. ExactSpelling:=True, SetLastError:=True)> _
    8. Public Shared Function keybd_event(ByVal bVk As Byte, ByVal bScan As Byte, _
    9. ByVal dwFlags As Int32, ByVal dwExtraInfo As Int32) As Boolean
    10. End Function
    12. Private Const VK_CAPITAL As Integer = &H14
    13. Private Const KEYEVENTF_EXTENDEDKEY As Integer = &H1
    14. Private Const KEYEVENTF_KEYUP As Integer = &H2
    16. Sub SetCaps(ByVal Status As Boolean)
    17. If Status Then
    18. If Not Control.IsKeyLocked(Keys.CapsLock) Then
    19. ToggleCapsLock()
    20. End If
    21. Else
    22. If Control.IsKeyLocked(Keys.CapsLock) Then
    23. ToggleCapsLock()
    24. End If
    25. End If
    26. End Sub
    28. Private Sub ToggleCapsLock()
    29. ' Toggle CapsLock
    31. ' Simulate the Key Press
    32. keybd_event(VK_CAPITAL, &H45, KEYEVENTF_EXTENDEDKEY Or 0, 0)
    34. ' Simulate the Key Release
    35. keybd_event(VK_CAPITAL, &H45, KEYEVENTF_EXTENDEDKEY Or KEYEVENTF_KEYUP, 0)
    36. End Sub
    38. Private Sub btCapsLockOff_Click(sender As Object, e As EventArgs) Handles btCapsLockOff.Click
    39. SetCaps(False)
    40. End Sub
    42. Private Sub btCapsLockOn_Click(sender As Object, e As EventArgs) Handles btCapsLockOn.Click
    43. SetCaps(True)
    44. End Sub
    45. End Class



    In VB programmiere ich normaler nicht, nur in C#. Aber ich hatte halt langeweile ;)

    @RodFromGermany
    @Trade
    In diesem Fall kann ich die Aufregung nicht verstehen.

    VB.NET-Quellcode

    1. Public Declare Function GetAsyncKeyState Lib "User32" (Key As Int32) As Int32

    C#-Quellcode

    1. [DllImport("User32", CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = true)]
    2. public static extern int GetAsyncKeyState(int Key);


    VB.NET-Quellcode

    1. <System.Runtime.InteropServices.DllImport("User32")> _
    2. Public Shared Function GetAsyncKeyState(Key As Int32) As Int32
    3. End Function

    C#-Quellcode

    1. [DllImport("User32")]
    2. public static extern int GetAsyncKeyState(int Key);


    Also alles was Declare macht, ist beim DllImport-Attribut noch CharSet, ExactSpelling und SetLastError zu setzen. Und ganz ehrlich... Die Syntax mit Declare finde ich wesentlich besser lesbar, als mit dem DllImport-Attribut.

    Das wäre das gleiche, wie wenn ich sagen würde, man dürfte in C# nicht sowas schreiben:

    C#-Quellcode

    1. public static string Foo(this int bar) { ... }
    Sondern man muss es explizit mit Attribut machen:

    C#-Quellcode

    1. [System.Runtime.CompilerServices.Extension()]
    2. public static string Foo(int bar) { ... }


    Ich würde ja nichts sagen, wenn bei Declare irgend ein Blödsinn kompiliert werden würde, aber da passiert genau das gleiche, wie wenn mans manuell mit DllImport-Attribut hinschreibt.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Cheffboss schrieb:

    VB.NET-Quellcode

    1. Public Declare Function GetAsyncKeyState Lib "user32" (ByVal vKey As Long) As Integer
    2. Private Declare Function GetKeyState Lib "user32.dll" (ByVal nVirtKey As Long) As Integer

    Niko Ortner schrieb:

    In diesem Fall kann ich die Aufregung nicht verstehen.
    As Long
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @RodFromGermany
    Ok, in Deinem Fall hab ich das falsch verstanden.

    Edit:
    @Trade
    Ich trotzdem gerne Deine Meinung dazu hören.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Niko Ortner“ ()

    Niko Ortner schrieb:

    Ich trotzdem gerne Deine Meinung dazu hören.

    Du nix deutsch? :P

    Also ich hatte mich nie wirklich mit ILSpy mal hinter das Declare geklemmt. Ist halt nicht mehr wirklich aktuell und ich halte mich da immer ganz strikt dran.
    Habe ja auch nicht gesagt, dass es schlecht ist, habe nur gesagt, dass es halt älter ist und das moderne DllImport wäre.
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Du nix deutsch? :P

    Ups, hatte den Satz zuerst anders stehen und beim Umbauen ist wohl was daneben gegangen.

    Mich wundert's nur immer, warum Declare so verpönt ist.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Naja, sicherlich ist nicht alles Müll, aber halt das Meiste. Und um sowas zu vermeiden nehme ich halt das .NET-konformere, weil ich ja nicht immer mit ILSpy hinterherrennen kann. ;)
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Das wird passend zum DllImport umgesetzt. Letztendlich also dasselbe, nur dass der direkte DllImport mehr bietet. Warum sollte ich da irgendwas mit Declare schreiben, wenn's sowieso zum DllImport wird? Das ist nur zur Abwärtskompatibilität drin, damit die VB6'ler sich nichts Neues angewöhnen müssen ;) .

    @Gonger96
    Declare ist tatsächlich nicht so flexibel, aber ich habe noch nie mehr als <DllImport("Name")> gebraucht.

    Die Declare-Variante lässt sich (meiner Meinung nach) wesentlich einfacher schreiben (so wie sich in C# die Variante mit this bei Extensions leichter schreiben lässt).
    Dazu kommt, dass man beim DllImport-Attribut entweder jedes Mal System.Runtime.InteropServices.DllImport schreiben muss, oder in jeder Datei mit externen Methoden Import System.Runtime.InteropServices schreiben muss.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Niko Ortner schrieb:

    Declare ist tatsächlich nicht so flexibel, aber ich habe noch nie mehr als <DllImport("Name")> gebraucht.

    Ich wohl.

    Ob sich etwas leichter schreiben lässt, hat garnichts zu sagen. Für viele ist eine GoTo deutlich schneller zu schreiben und übersichtlicher, als ein If-Block. Erfüllt ja auch den selben Zweck, trotzdem benutzt man If. Ob das jetzt an einem Namespaceimport scheitern soll? Dann importier ich mir lieber direkt Microsoft.VisualBasic und lass den Rest einfach weg.

    @Gonger96
    Auch wieder wahr.
    Wobei man sagen muss: Ein Goto ist sicher nicht einfacher zu schreiben, als ein einfaches If. Man muss ja auch den Cursor auf die Zielposition bewegen, dort Labelname: schreiben, Cursor zurück, und dann den Sprung schreiben. (Übrigens, wie würde man den dann machen? If Bedingung Then Goto Foo?)
    Was aber viel wichtiger ist: Der Wartungsaufwand beim Goto ist viel höher als beim If. Dagegen ist der Wartungsaufwand beim Declare ähnlich gering wie beim DllImport-Attribut.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

Facebook
Telefonspende