Visual Basic: Account Creator erstellen?

[Marsimoto']

Hey,
Ich hatte vor einen Account Creator zu erstellen und wollte fragen wie genau das funktioniert. Ich würde gerne z.B einen Web Mail Account Creator erstellen der Namen, Geburtstag, Passwort etc. Selbst generiert und ausfüllt und nur ein captcha manuell eingegeben werden muss. Hoffe ihr könnt mir helfen :-)

[Mostey]

Die General Coding Sektion ist kein Wunschbrunnen. Das ist dir klar, oder?

Wo genau ist das Problem?

[MrSm!th]

#moved

[Marsimoto']

Originally Posted by Mostey

Die General Coding Sektion ist kein Wunschbrunnen. Das ist dir klar, oder?

Wo genau ist das Problem?

Mein Problem liegt darin das ich nicht weiß wie ich das so einstellen kann das er Namen, GB Datum etc. selbst generiert und einträgt und generell so ein Acc Creator zu erstellen.

[Syc]

Namen generieren -> Große Namensliste ausm Netz laden und da immer einen Namen rausziehen.
Gb einfach randomzahlen generieren, halt auf legitime daten achten.

Wie die du Registrierung selber gestaltest, wurde hier so oft schon diskutiert. Stichwort: httpwebrequest (gibt sogar ein tut darüber in der coding tutorials sektion)

Wie man ein Captcha bei einer Registrierung ausliest findest du bestimmt auch mit der SuFu in exakt dieser Sektion, wurde schon oft durchgekaut.

[Marsimoto']

Originally Posted by Sycophantic

Namen generieren -> Große Namensliste ausm Netz laden und da immer einen Namen rausziehen.
Gb einfach randomzahlen generieren, halt auf legitime daten achten.

Wie die du Registrierung selber gestaltest, wurde hier so oft schon diskutiert. Stichwort: httpwebrequest (gibt sogar ein tut darüber in der coding tutorials sektion)

Wie man ein Captcha bei einer Registrierung ausliest findest du bestimmt auch mit der SuFu in exakt dieser Sektion, wurde schon oft durchgekaut.

Okay ich klick mich durch danke

[PC Jones]

Originally Posted by .ViO

Okay ich klick mich durch danke

Wenn du HttpWebRequest lernst, übe dich an diesem Tutorial:


Und fange bloß nicht mit sowas wie Web.de an, daran scheitern sogar erfahrene Leute

[Hurt Locker]

Bin mir nicht sicher ob du sowas meinst, aber du kannst es mal versuchen:

Und hier Teil 2, dieser sollte das beinhalten was du benötigst:

[Marsimoto']

Originally Posted by Todbringer�

Bin mir nicht sicher ob du sowas meinst, aber du kannst es mal versuchen:

Und hier Teil 2, dieser sollte das beinhalten was du benötigst:

Werds mir mal anschauen danke

[Syc]

Originally Posted by Todbringer�

Bin mir nicht sicher ob du sowas meinst, aber du kannst es mal versuchen:

Und hier Teil 2, dieser sollte das beinhalten was du benötigst:

Kurz mal das erste Video überflogen:
Webbrowser ist bad habit für faule und nicht empfehlenswert.
Genau wie Application.DoEvents().

Aus diesem Grund lieber ein richtiges Tutorial hernehmen und kein billiges Youtubetutorial. Wenn man was programmieren will, dann richtig.

[Mostey]

Originally Posted by Sycophantic

Kurz mal das erste Video überflogen:
Webbrowser ist bad habit für faule und nicht empfehlenswert.
Genau wie Application.DoEvents().

Aus diesem Grund lieber ein richtiges Tutorial hernehmen und kein billiges Youtubetutorial. Wenn man was programmieren will, dann richtig.

Wenn du schon sagst, das es bad habit ist, dann schreib bitte auch den Grund dazu.

Hmya, the enduring mystique of DoEvents(). There's been an enormous amount of backlash against it, but nobody ever really explains why it is "bad". The same kind of wisdom as "don't mutate a struct". Erm, why does the runtime and the language supports mutating a struct if that's so bad? Same reason: you shoot yourself in the foot if you don't do it right. Easily. And doing it right requires knowing exactly what it does, which in the case of DoEvents() is definitely not easy to grok.

Right off the bat: almost any Winforms program actually contains a call to DoEvents(). It is cleverly disguised however with a different name: ShowDialog(). It is DoEvents() that allows a dialog to be modal without it freezing the rest of the windows in the app.

Most programmers want to use DoEvents to stop their user interface from freezing when they write their own modal loop. It certainly does that, it dispatches Windows messages and gets any paint requests delivered. The problem however is that it isn't selective. It not only dispatches paint messages, it delivers everything else as well.

And there's a set of notifications that cause trouble. They come from about 3 feet in front of the monitor. The user could for example close the main window while the loop that calls DoEvents() is running. That works, user interface is gone. But your code didn't stop, it is still executing the loop. That's bad. Very, very bad.

There's more: the user could click the same menu item or button that causes the same loop to get started. Now you have two nested loops executing DoEvents(), the previous loop is suspended and the new loop is starting from scratch. That could work, but boy the odds are slim. Especially when the nested loop ends and the suspended one resumes, trying to finish a job that was already completed. If that doesn't bomb with an exception then surely the data is scrambled all to hell.

Back to ShowDialog(). It executes DoEvents() but do note that it does something else. It disables all the windows in the application, other than the dialog. Now that 3 feet problem is solved, the user cannot do anything to mess up the logic. Both the close-the-window and start-the-job-again failure modes are solved. Or to put it another way, there is no way for the user to make your program run code in a different order. It will execute predictably, just like it did when you tested your code. It makes dialogs extremely annoying, who doesn't hate having a dialog active and not being able to copy and paste something from another window? But that's the price.

Which is what it takes to use DoEvents safely in your code. Setting the Enabled property of all your forms to false is a quick and efficient way to avoid problems. Of course, no programmer ever actually likes doing this. And doesn't. Which is why you shouldn't use DoEvents(). You should use threads. Even though they hand you a complete arsenal of ways to shoot your foot in colorful and inscrutable ways. But with the advantage that you only shoot your own foot, it won't (typically) let the user shoot hers.

The next versions of C# and VB.NET will provide a different gun with the new await and async keywords. Inspired in small part by the trouble caused by DoEvents and threads but in large part by WinRT's api design that requires you to keep your UI updated while an asynchronous operation is taking place. Like reading from a file.

Ich hatte mal ein Framework (für Flat Design) in WinForms verwendet und hatte genau das gleiche Szenario gehabt, das der Kerl da beschrieben hat. Die Message Loop lief weiter und 2 Sekunden nach dem Schließen des Hauptfensters flog die Stackoverflow Exception. Bisher wusste ich nicht, was das verursacht hat aber jetzt weiß ich's.