> この"*アメーバIDもしくはパスワードを確認して下さい*"を　URLにして実行することは可能でしょうか？
メッセージ部分をURL に変換した上で実行させる……?
ごめんなさい、仰っている意味が理解できませんでした。


>  名前　　　　 値　　　　　　形
> InnerText Nothing Object
> こんな感じですね。

「形」というのは「型」のことでしょうか。

せっかく投稿していただいたものの、これだけでは何に対する調査結果を
報告しておられるのか分からないので、もう少し追加説明を加えて頂けると助かります。


…恐らくは、ウォッチウィンドウの内容を書いて頂いたものと推察しますが、
いつ、どのスコープでそれが表示されているのかといったことが分からないため、
こちらで現象を再現させるには至っていません。

仮に、予想通りウォッチ式だったとして…どこかに InnerText という名前の変数を
用意しているのでしょうか。確認するのは InnerText プロパティではなく?

もし、最初のコードのまま実行したとすれば、InnerText という変数は無いため、
下記 ★１のように表示されるかと思います。


★１：変数自体が存在しない場合


★２：Object型の変数として宣言されていた場合



> Button1.Visible = Flash
>にすると、Button1がFalsh
Flash でも Falsh でもなく、False ですよね。
間違ったスペルで記憶されているようなので、この際しっかり覚えてしまいましょう。



> ?amebaId=" & Me.TextBox1.Text & "&password=" & Me.TextBox2.Text

パスワード等は流石に公開できないでしょうし、自分もアカウントを
持ち合わせているわけではないので、検証しようも無いのですが、
ここに指定している URL 自体は間違いないのですね?

なお、本来であれば、URL に埋め込む文字列はエンコードされねばなりません。
そのため Navigate する前には、TextBox の中身を検証し、必要に応じて
UrlEncode するようなコードを組み込むのが望ましいです。



> そして、僕の予想では "*アメーバIDもしくはパスワードを確認して下さい*"に対するElseなので
> 勿論、Else以降は"*アメーバIDもしくはパスワードを確認して下さい*"が表示されていない場合の
> Button1がFalsh　WebBrowser1がTrue　です。

ステップ実行すれば、予想が当たっているかどうかを容易に確認できますね。


> とりあえず参考URLは
それだけたくさんの URL が使われるのに、DocumentCompleted イベント内での処理が、
たったの 2 分岐で本当に良いのでしょうか。もっと細かい場合分けが必要であるように感じます。


> ログインしている時と、していない時と、対応が違います。
ログインに成功した場合と失敗した場合とで、
遷移先の e.URL もしくは Document の内容が異なるのですね?

であれば、それらが具体的にどのように違うのかを調査・分析してみてください。
調査しない事には、それに対するコードの書き方も分かりません。

どのように違うのかを知っているのは私ではなく、他でもないだるさんさん自身なのですから。



> どうしればいいでしょうか。

こういった機械的なアクセスの仕方は、サイト運営者が嫌うところでもあるので、
まずは、『運営者側に許可を取った上で開発するべき』かと思います。

今回提示していただいた URL は、開発者向けに Web API として公開されているような
ものではなく、一般ユーザーがブラウザ経由で利用することを前提としたものですよね?

以前はアメーバでも一般向けに開発者用APIが公開されていましたが、現在は公開を終了しています。
API として公開されているものを使う分には、あまり問題とはなりませんが、
一般利用者向けの URL をそのまま使う場合は、いろいろとデリケートな問題が関わってきます。


たとえば、ページの使いやすさの向上のため、ページあたりの滞在時間などを
運営者側が調査しようとした場合、機械的なアクセスは集計の邪魔となります。

あるいは、自動巡回ツールを使ってスクレイピングする行為が多発した場合、
広告等を見ることなくデータだけを無人で読み書きできてしまうので、
それが正常な運営の妨げになると判断される場合もあります。


また、ログイン補助のツールの作り方を掲示板で根掘り葉掘り聞いたり、あるいは
そのツールを公開したとすると、それらが、DoS の温床やチート行為を
招くことにもなりかねません。たとえば、多数のパスワードを順に試して
アカウントをハックしようとする辞書攻撃なども可能となるからです。

もちろんご本人にはその気が無いでしょうが、第三者が悪用する可能性を増大させるとの
理由から、サイト運営者側からの警告、時にはアカウントの停止/抹消といった対処が
取られたケースもあります。アメーバがそうであるかどうかは分かりませんが。


たとえ本人しか使わない非公開ツールで、しかも開発者側に悪用目的は一切無かったとしても、
それによってWeb サービスを停止させてしまう事態となった場合、たとえその原因が
サーバー側の不具合が原因だったとしても、無許可の自作ツールでサービスを停止に
追いやったとして、開発者が逮捕されてしまうことも実際にありましたし。
(Librahack 事件／岡崎図書館事件)