ここまでスレッドのサンプルを書いてきたのですが、主にプログラムがみにくくなるとか、めんどいとか、動くからえぇやんという理由で、やるべきことをやってないところがあります。 スレッドからのSwing操作とwaitの処理です。 Swingはシングルスレッドモデルで実装されているので、GUIスレッドとは別のスレッドからSwingを操作するべきではありません。EventQueue#invokeLaterなどを使って処理をGUIスレッドにのせる必要があります。(SwingUtilities#invokeLaterは内部でEventQueue#invokeLaterを呼び出しているだけです) 今回の一連のサンプルで使っているJTextField#setTextや、今回は使ってないけどよく使うJTextArea#appendなど、JTextComponentのテキスト操作に関しては、幸いスレッドセーフなの
リクエストパラメータの入力をテーブルに変更する ついでにメニューもつけておく このアプリケーションについてはとりあえずここまで。 ここから先を作りこむならgriffonに移植するほうがいいかな import groovy.swing.SwingBuilder import groovy.json.JsonOutput import groovy.json.JsonSlurper import groovy.beans.Bindable import javax.swing.* import javax.swing.tree.DefaultMutableTreeNode as TreeNode import java.awt.* import java.net.* def manager = new CookieManager() manager.cookiePolicy = CookieP
TMGridBagLayoutについて はじめに Java 8でJava FXが標準ライブラリ扱いとなりましたが、今でもSwingを使う人はたくさんいます。私もJava FXの基本的なGUI部品(TreeView等)がまだ扱いづらいと感じていて、未だに積極的に使おうという気分になれません。今でも、簡単なGUI部品ならSwingで済ませてしまいます。 Swingでは画面にGUI部品を配置するにはレイアウトマネージャ(java.awt.LayoutManager2の実装クラス)を使うわけですが、自分が満足に使えるものがJava標準ライブラリにはありません。GridBagLayoutもちょっと今ひとつです。 というわけで、レイアウトマネージャを作りました。 TMGridBagLayoutのご紹介 自作レイアウトマネージャは、GridBagLayoutとGridBagConstraintsを拡張し
概要 自分の確認用に製作したSwingの基礎を説明したサンプルコードです。Javaでゲームを作ろうとしている初心者(=俺)に向けて、少しでも参考になればと思った次第です。 プログラム自体は赤い矩形が大きくなったり小さくなったりする、ごく単純なプログラムなのですが、 JFrame や JPanel、Event取得やThread等、おおよそゲーム製作に必要になるであろう技術を可能な限り簡潔に詰め込みました。 BasicDrawing.java /* javax.swing における 2D描画の基礎 */ import javax.swing.JFrame; import javax.swing.JPanel; import java.awt.Color; import java.awt.Container; import java.awt.Graphics; import java.awt.B
ステータスバーもどき(Swing) Swingには、ステータスバーそのものは用意されていない。 JFrame#getContentPane()の下方にそれっぽいコンポーネントを配置することで代用する。 単純なラベル 少し複雑な配置 [/2007-02-08] ツールバーとの並存 単純なラベル /** * ステータスバーの初期化 */ private void initStatusBar(Container c) { JLabel bar = new JLabel("status"); c.add(bar, BorderLayout.PAGE_END); } 少し複雑なステータスバー 左詰のペインを用意し、その上に必要なコンポーネントを配置する例。 /** * ステータスバーの初期化 */ private void initStatusBar(Container c) { JPanel ba
swingでGUIアプリを作成した場合、RuntimeExceptionやError等のチェック例外じゃないものは、Event Dispah Therad(EDT)が処理する事になる。 なので、ユーザへ通知されない為「何も起きないぞ!! もう一度ボタン押してみるか、やっぱり何も起きない!!! なんだこのクソアプリ!!!!」となってしまう。GUIなんで、コンソールへ出力されたstacktraceに気付くことは、皆無でしょう。 "エラーが発生しました"くらいのダイアログは、表示したいです。 そこで、EDTにユーザ作成のエラー処理を呼びだしてもらう方法を考えてみます。 うんともすんとも言わないswingアプリ 以下のプログラムをサンプルとします。 実行すると、3つボタンが表示され、 「Exception」ボタンを押すと、自前でtry〜catchしてるので、エラーdialogが表示されます。 「R
※ Java8 から Swing から JavaFX への移行を推奨している。 Swingとは [2014-10-08] Swingはスレッドセーフではない [2014-10-08] 時間がかかる処理はSwingWorkerを使う [2014-10-08] EDT上でスレッドを固めない SecondaryLoop (モーダルダイアログの仕組み) [2015-02-08] JTextArea の行間を変える( JTextPane や JEditorPane は使用しない) [2015-02-11] Swingとは Swingは、プログラミング言語 Java のGUIツールキット。 同じく Java の GUI ツールキットである AWT を拡張したもの。 AWT はオペレーティングシステムのウィンドウシステムに準じたデザインになるのに対し、 Swing で作成した GUI は Java プロ
動機、なぜJavaFXでアプリを作るのか? Javaには、Swingという、十分に成熟しておりパフォーマンスも悪くないUIライブラリがある。 現状、普通に使っている分には何の不自由もない。 また、Swingは今後発展することはないとはいえ、(すぐに)廃止されるわけではない。*1 ※ 2018/9以降、JavaFXはOpenJDK, OracleJDKともに同梱されないことになった。すなわち、JavaFXはJavaの標準のツールキットではなくなる。なので、無理にJavaFXを勉強しなくてもいいかもね。(というか、Oracleの業態からいってクライアント向けの機能は必要としていないから、今後はGuiまわりは全部切られるかも?) 2018/6/2追記 ※ Java11でJavaFXを使う方法について記事を書きました。(2018/7/27) ならば、どうしてJavaFXなどという、新しいUIライブ
FileModel model = new FileModel(); JTable table = new JTable(model); DropTargetListener dtl = new DropTargetAdapter() { @Override public void dragOver(DropTargetDragEvent dtde) { if (dtde.isDataFlavorSupported(DataFlavor.javaFileListFlavor)) { dtde.acceptDrag(DnDConstants.ACTION_COPY); return; } dtde.rejectDrag(); } @Override public void drop(DropTargetDropEvent dtde) { try { if (dtde.isDataFlavor
Swingは、シングルスレッド設計になっています。 これはつまり、Swingにて各コンポーネントの描画およびイベントのディスパッチ処理などは 一つのスレッドで行われるという事になります。 その処理を実際に行うスレッドをイベントディスパッチスレッドといいます.(Event Dispatch Thread: EDT) Swingでアプリを作成する場合、この点をしっかり考慮しないと変なバグがでます。 (いきなりArrayIndexOutOfBoundExceptionやNullPointerが発生したり) そして、Swingには上記の点に関連して以下のルールが存在します。 Sun Developer Network(SDN)のThreads and Swingより抜粋 http://java.sun.com/products/jfc/tsc/articles/threads/threads1.h
前回までの記事 http://d.hatena.ne.jp/gsf_zero1/20061104/p1 http://d.hatena.ne.jp/gsf_zero1/20061106/p1 前回、イベントディスパッチスレッドにて時間のかかる処理を行うとGUIがブロックされる 件について記述しました。そのような処理を行う場合、Swingでは以下のようにします。 時間のかかる処理の部分を別スレッドにする 上記の処理が終了した後で、コンポーネントをイベントディスパッチスレッドから更新 (1)は特に問題ありません。処理を別のスレッドに移すだけです。問題となるのが (2)です。時間のかかる処理を行った後で、コンポーネントを処理するわけですので 当然時間のかかる処理を行ったスレッドで行わざるをえないような形になってしまいます。 つまり、以下のような感じです。 jButton.setText("heh
SwingUtilities#invokeLaterは理解しづらい SwingのSwingUtilities#invokeLaterについてちょっと調べてみたが、よくわからないのでもっと調べてみた。 SwingのSwingUtilities#invokeLaterがわからなくなってしまうのは、その「後で実行する」という名前に反して「イベントディスパッチャスレッドに処理を依頼する」という使われ方が主だからだ。 もう名前を変えちまえ。 以下にその使われ方をまとめていこう。 構築および始動 Swingオブジェクトはシングルスレッド設計で、単一のスレッド(イベントディスパッチャスレッド)からしかアクセスしてはならないということになっている。 これはSwingコンストラクタおよびsetVisibleも例外ではない。 そのため、時々*1次のようなサンプルを見かける。 public static voi
JavaとSwingを使い、JRE(Java Runtime Environment)をインストールしたコンピュータで実行可能なGUIアプリケーションを作ってみる。 環境 Windows 8.1 Pro 64 bit版 >systeminfo OS 名: Microsoft Windows 8.1 Pro OS バージョン: 6.3.9600 N/A ビルド 9600 OS ビルドの種類: Multiprocessor Free システムの種類: x64-based PC プロセッサ: 1 プロセッサインストール済みです。 [01]: Intel64 Family 6 Model 69 Stepping 1 GenuineIntel ~1596 Mhz JDK 8のインストール まず、JDKのダウンロードページからWindows x64用のインストーラをダウンロードし、JDK 8をインスト
シングルスレッド設計 一般的に Swing はシングルスレッド設計であり、他のスレッドが介入してはいけない 逆に言えば、Swing は常に一つのスレッドからのみアクセスすることができます なぜ、Javaの得意分野である「マルチスレッド」を切り捨てるようなことをしたのでしょうか? マルチスレッドはプログラムが複雑で上級プログラマであっても困難といわれます スレッドセーフクラスを拡張するということは、プログラマも熟練者である必要があります また、スレッドの状態をチェックし同期をとるという動作もオーバーヘッドにつながります このような拡張の簡易化や動作の合理化のために Swing はシングルスレッド設計なのです 正確には、Swing コンポーネントが描画されてからが対象になります その後は、イベントディスパッチスレッドからのみアクセス可能となります イベントディスパッチスレッドとは、コールバック
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く