Indexへ
(3384)//【3359】→(3360)
------------------------
【タイトル】両ボタンドラッグによる縮小について。
【記事番号】 3359 (*)
【 日時 】05/09/13 15:27
【 発言者 】武蔵

　武蔵です。両ボタンドラッグの縮小操作時の動作について述べさせていただきます。

　現在は、両ボタンドラッグの縮小は、マウスドラッグにより縮小を指示すると、あらかじめ決められた倍率で、縮小します。反面、拡大はマウスにより範囲を指定し、比較的任意の倍率で拡大することができます。
　そこで両ボタンドラッグによる縮小時は、マウスのドラッグ量に比例してリアルタイムで縮小された図形を表示させて、画面で図形を確認しながら縮小できると、操作性が良くなると思います。

　悪筆で贅沢なことを述べさせていただきました。失礼しました。


Indexへ
(3359)←【3360】→(3363)
------------------------
【タイトル】Re(1):両ボタンドラッグによる縮小について。
【記事番号】 3360 (3359)
【 日時 】05/09/13 16:29
【 発言者 】joker
【 リンク 】http://www.atsmile.com/jw/



▼武蔵さん：
>　そこで両ボタンドラッグによる縮小時は、マウスのドラッグ量に比例してリアルタイムで縮小された図形を表示させて、画面で図形を確認しながら縮小できると、操作性が良くなると思います。

拡大の時には、リアルタイムなのは必要無いのでしょうか？
だとしたら、いまいち統一感がないですね。

リアルタイムに拡大・縮小がしたいのならば、現状でも、
ホイールによる拡大・縮小が可能ですが、それではダメなのでしょうか？

また、マウスを動かすたびに再描画を繰り返すのならば、重たい図面だと
厳しいような気もします。
以前から、マウスドラッグ中に、再描画によるタイムラグ？で、
クロックメニューに移ってしまう、という件も、更にひどい状況に
なりそうな気もします。

これを高速・安定に動作させるようにして欲しい、つまり、画面作図ロジックの
大きな変更を余儀なくされるような気がして、ちょっと、恐ろしい気はしますね。
例えば、
ドラッグ中は、仮の、ラスターデータ的な拡大・縮小・移動を行って、
マウスボタンを離したら実際の作図を行う、とか。そういう市販CADもあるけれど
根本的な部分が随分違うような、そんな気はしますね。


Indexへ
(3360)←【3363】→(3369)
------------------------
【タイトル】ホイール及びリアルタイムについて。
【記事番号】 3363 (3360)
【 日時 】05/09/14 10:44
【 発言者 】武蔵

▼jokerさん：レスありがとうございます。

>拡大の時には、リアルタイムなのは必要無いのでしょうか？
>だとしたら、いまいち統一感がないですね。

　現状も、拡大は範囲指定ですし、縮小はマウス指定位置中心での表示倍率変更と統一
されているわけではありませんが、慣れている方が多いと思いますので、チェックボックスなどで選択するようにするのが理想的だと思っております。

>リアルタイムに拡大・縮小がしたいのならば、現状でも、
>ホイールによる拡大・縮小が可能ですが、それではダメなのでしょうか？

　リアルタイムという表現を訂正させていただきます。ホイールによる拡大・縮小と同じ仕様でよいと思っております。ドラッグ開始位置を中心に基本設定で指定した倍率で縮小する。
　そこで、今思いついたのですが、例えばドラッグ開始位置より左にドラッグで縮小しそのままドラッグを継続し、ドラッグ開始位置より右にドラッグすると拡大もでき、ドラッグ終了で表示倍率を確定するというのは、いかがでしょうか？
　ますます、ホイールによる拡大・縮小みたいですね。
　これによるメリットは、指の関節がつらくてホイールの操作するのがつらい人でもドラッグなら苦にならないという限られたユーザー（私もです）やホイールの操作が苦手な人
にも、さらには２ボタンマウスのユーザーにも（いるはずです。）、ｊｗｃａｄで快適に作図できるようになると思っております。
　
>また、マウスを動かすたびに再描画を繰り返すのならば、重たい図面だと
>厳しいような気もします。
>以前から、マウスドラッグ中に、再描画によるタイムラグ？で、
>クロックメニューに移ってしまう、という件も、更にひどい状況に
>なりそうな気もします。
>
>これを高速・安定に動作させるようにして欲しい、つまり、画面作図ロジックの
>大きな変更を余儀なくされるような気がして、ちょっと、恐ろしい気はしますね。
>例えば、
>ドラッグ中は、仮の、ラスターデータ的な拡大・縮小・移動を行って、
>マウスボタンを離したら実際の作図を行う、とか。そういう市販CADもあるけれど
>根本的な部分が随分違うような、そんな気はしますね。

　リアルタイムという言葉がまずかったです、すいませんでした。上記の通り訂正させていただきました。
　
　以上です。


Indexへ
(3363)←【3369】→(3371)
------------------------
【タイトル】どうもよく分かりませんが
【記事番号】 3369 (3363)
【 日時 】05/09/14 17:26
【 発言者 】joker
【 リンク 】http://www.atsmile.com/jw/



▼武蔵さん：
> ドラッグ開始位置より左にドラッグで縮小しそのままドラッグを継続し、ドラッグ開始位置より右にドラッグすると拡大もでき、ドラッグ終了で表示倍率を確定するというのは、いかがでしょうか？
> ますます、ホイールによる拡大・縮小みたいですね。
> これによるメリットは、指の関節がつらくてホイールの操作するのがつらい人でもドラッグなら苦にならないという限られたユーザー（私もです）やホイールの操作が苦手な人にも、さらには２ボタンマウスのユーザーにも（いるはずです。）、ｊｗｃａｄで快適に作図できるようになると思っております。

申し訳ありませんが、おっしゃっているイメージが、実のところ、
よく分かりません。

現在は、
左右ボタン・右下ドラッグで拡大範囲を指定して、拡大、
左右ボタン・左上ドラッグで、縮小、
ですが、
「左右ボタン」同時、というのは、同じで良いのですよね？
右下ドラッグ、左上ドラッグ、というのも同じ。

では、どこが違うのか、となると、
範囲選択をするのではなく、例えば、ステータスバー右の　拡大倍率表示部が
ドラッグ中に、数字がカウントアップ・カウントダウンされ、
マウスのボタンを離すと、その倍率で画面表示する、という意味なのでしょうか？
だとしたら、
１）Windowsは、イベントドリブン（何かをしたら、それに応じた処理をする）
　　で動作を行うシステムですが、その操作は「何もしていない」事になりますが
　　何もしていない場合に何らかの処理を行うには、無限ループ状態にするか、
　　タイマ割り込みにする必要があります。C/C++の場合には、mainで書くという
　　手もあるのかな？よく分かりませんが、これはやりたくないでしょう。
　　無限ループを作り出すのは、はっきり言って、危険です。
　　下手をすれば、JWWがフリーズ状態になる可能性がありますし、
　　Windows9xの場合、Windowsが死にます。
　　DOS時代ならともかく、Windowsアプリでは、何もしていない時に何らかの
　　処理を行う、というのは、結構、やっかいな問題です。
２）カウントの増え方・減り方
　　単純なループだと、CPUが遅ければ、遅く、CPUが速ければ、速く、カウント
　　されてしまうので、どのみち、100ms経ったらカウント0.1、とかになると
　　思いますが、もっと大きく変化させたい、となると、指定範囲を大きくする
　　とかにするとして、まぁそれはいいですが、
　　果たして、拡大率という数値で、実際、どのくらいの部分を拡大・縮小を
　　しているのか、感覚的に分かるのか？　という問題。
３）従来との操作がまるで違う
　　例えば私なんかは、まるで全然違うソフトなのに、つい、左右ドラッグで
　　拡大しようとしてしまいます。(笑)　それくらい、拡大・縮小というのは
　　ごくごく普通の操作で、慣れ、というものがありますが、
　　この処理は、従来と全く違ったシステムですが、
　　万民、とは言いませんが、JWWユーザーの少なくとも 1/10 が賛成して
　　積極的に使うような機能でしょうか？
　　機能的には、面白いと思います。
　　しかし、面白いのと、果たしてそれが、有効的・機能的で便利なものなのか？
　　というのとは、別だと思います。
って感じでしょうか？

ちなみにこれは、私の勝手な想像ですので、全ての判断は、JWW作者さんが
されると思います。


Indexへ
(3369)←【3371】→(3374)
------------------------
【タイトル】わかっていただけましたでしょうか？
【記事番号】 3371 (3369)
【 日時 】05/09/14 19:10
【 発言者 】武蔵

▼jokerさん：レスありがとうございます。

>現在は、
>左右ボタン・右下ドラッグで拡大範囲を指定して、拡大、
>左右ボタン・左上ドラッグで、縮小、
>ですが、
>「左右ボタン」同時、というのは、同じで良いのですよね？
>右下ドラッグ、左上ドラッグ、というのも同じ。
>
>では、どこが違うのか、となると、
>範囲選択をするのではなく、例えば、ステータスバー右の　拡大倍率表示部が
>ドラッグ中に、数字がカウントアップ・カウントダウンされ、
>マウスのボタンを離すと、その倍率で画面表示する、という意味なのでしょうか？

　おっしゃる通りです。

>１）Windowsは、イベントドリブン（何かをしたら、それに応じた処理をする）
>　　で動作を行うシステムですが、その操作は「何もしていない」事になりますが
>　　・・・・中略。

　　mousemoveイベントとマウスの移動量（相対位置）を演算することで対応可能かと
　思います。

>２）カウントの増え方・減り方
>　　単純なループだと、CPUが遅ければ、遅く、CPUが速ければ、速く、カウント
>　　されてしまうので、どのみち、100ms経ったらカウント0.1、とかになると
>　　思いますが、もっと大きく変化させたい、となると、指定範囲を大きくする
>　　とかにするとして、まぁそれはいいですが、
>　　果たして、拡大率という数値で、実際、どのくらいの部分を拡大・縮小を
>　　しているのか、感覚的に分かるのか？　という問題。

　　１．timerイベントを使ってまで、実装するほどのことではないと思います。
　　２．拡大・縮小率は、基本設定にすでに実装されています。
　　　ドラッグの基点を中心に拡大・縮小している様子が視覚的に判るようになると思い　　　ます。前述しましたが、ホイールによる拡大・縮小と同じ感覚になると思います。

>３）従来との操作がまるで違う
>　　例えば私なんかは、まるで全然違うソフトなのに、つい、左右ドラッグで
>　　拡大しようとしてしまいます。(笑)　それくらい、拡大・縮小というのは
>　　ごくごく普通の操作で、慣れ、というものがありますが、
>　　この処理は、従来と全く違ったシステムですが、
>　　万民、とは言いませんが、JWWユーザーの少なくとも 1/10 が賛成して
>　　積極的に使うような機能でしょうか？
>　　機能的には、面白いと思います。
>　　しかし、面白いのと、果たしてそれが、有効的・機能的で便利なものなのか？
>　　というのとは、別だと思います。
>って感じでしょうか？

　　これも前述しましたが、チェックボックスでユーザーが選択できるようにすること
　が必要と思います。
　　私も、エクセルやＡＵＴＯＣＡＤで両ボタンドラッグをしばしばやってしまいます。


>ちなみにこれは、私の勝手な想像ですので、全ての判断は、JWW作者さんが
>されると思います。

　　この機能が必要な人が多いことを期待しております。
　


Indexへ
(3371)←【3374】→(3387)
------------------------
【タイトル】Re(1):わかっていただけましたでしょうか？
【記事番号】 3374 (3371)
【 日時 】05/09/14 20:22
【 発言者 】coolyoppe

こんにちは。

基本設定＞一般(1)下から８行目「マウスの左または右ボタン〜
（R:縮小・拡大）」にチェックを付けると、マウス右ボタン
長押し（１秒以上）による拡大縮小（押した位置より上方向ドラッグ
で拡大、下方向で縮小）の操作が出来ますが、これを拡張して
『両ボタンでクリックした位置を中心に、ドラッグ量で拡大縮小の
早さを調整』
というご要望だと勝手に解釈しますが・・・。

私個人の意見としては、武蔵さんもご自分で仰っているように
機能としてはホイールでの拡大縮小とほぼ同じわけですし、
指の関節の件もホイールを回す操作のほうが両ボタンをドラッグ
する操作よりきついことは無いと思いますので、

あれば便利かとは思いますが、ズーム操作の多様性（ホイールで
大まかに拡大縮小、両ボタン（私はホイールボタン派）で範囲拡大
・全体・前倍率など）を犠牲にしてまでその設定にするユーザーは
多くないと思われます。

失礼しました。


Indexへ
(3374)←【3387】→(3388)
------------------------
【タイトル】補足させていただきます。
【記事番号】 3387 (3374)
【 日時 】05/09/15 12:24
【 発言者 】武蔵

▼coolyoppeさん：レスありがとうございます。

>『両ボタンでクリックした位置を中心に、ドラッグ量で拡大縮小の
>早さを調整』

　私の意見は
　『両ボタンでクリックした位置を中心に、ドラッグ量で拡大縮小の
　倍率を調整』
　　↑
　ここです。

>私個人の意見としては、武蔵さんもご自分で仰っているように
>機能としてはホイールでの拡大縮小とほぼ同じわけですし、

　機能というよりは、動作といったほうがよりわかりやすいと思います。
　
>指の関節の件もホイールを回す操作のほうが両ボタンをドラッグ
>する操作よりきついことは無いと思いますので、

　健常者の方であればそうでしょうね。ホイールの操作は指の曲げ伸ばし運動
になりますので・・・、回すタイプのホイールマウスを使わなければいいとい
う意見もあろうかと思いますが、車でいうとＡＴとＭＴくらい違う感じです。
ＡＴ（機械まかせ）、ＭＴ（ドライバーが任意に操作）。
わかりにくければ気にしないでください。ちなみに車はＭＴ派です。
　前述した通りの限られたユーザーを対象に需要があればいいと思っています。

>あれば便利かとは思いますが、ズーム操作の多様性（ホイールで
>大まかに拡大縮小、両ボタン（私はホイールボタン派）で範囲拡大
>・全体・前倍率など）を犠牲にしてまでその設定にするユーザーは
>多くないと思われます。

　私のいわんとしていることが正しく伝えられなかったかと思いますのでもう一考
していただけませんでしょうか？
　誤（速さ）⇔　正（拡大率）
　　このイメージの違いは、大きいと思います。


Indexへ
(3387)←【3388】→(3389)
------------------------
【タイトル】Re(1):両ボタンドラッグによる縮小について。
【記事番号】 3388 (3387)
【 日時 】05/09/15 13:08
【 発言者 】高橋

▼武蔵さん：

当方で要望を出すとすると、

基本設定で指定した倍率で縮小する。

という辺りになります。PageUpPageDownの設定の様にです。

個人的には、もう少し余計に縮小したくて、という理由です。

現状当方の操作は、拡大はドラッグ、縮小はスクロールになっています。


>
>　私の意見は
>　『両ボタンでクリックした位置を中心に、ドラッグ量で拡大縮小の
>　倍率を調整』
>　　↑
>　ここです。
>

拡大縮小とありますが、拡大の方は、個人的には今更という気がします。

縮小においては、あってもいいかなと思います。

ただこれについても、倍率の設定がなければ、大きく縮小するときに、

やたら大きくドラッグしなければならなくなってしまいます。


>
>　私のいわんとしていることが正しく伝えられなかったかと思いますのでもう一考
>していただけませんでしょうか？
>　誤（速さ）⇔　正（拡大率）
>　　このイメージの違いは、大きいと思います。

縮小率について、厳密に指定（いろいろな方法で）できたとしても

変化の状態が思ったほどではない、のではないか、というのが私の予想で、

過度に縮小して、拡大し直すというのが、簡便になればと思っております。


ちなみにDOS版の時は、小さく動かすと過度に縮小され、

大きく動かすと少しだけ縮小されていました。

武蔵さんが今回思ったのと逆の動きでしょうか。


　


Indexへ
(3388)←【3389】→(3391)
------------------------
【タイトル】Re(2):両ボタンドラッグによる縮小について。
【記事番号】 3389 (3388)
【 日時 】05/09/15 15:30
【 発言者 】名無し

拡大の時はドラッグ量に比例しているのに、縮小の時は比率が一定なのは使用感として変だなとは思いますが、実用的には見えない部分を予想してドラッグ量を決めるのは意外と大変です
DOS版の縮小の時は今の表示範囲を示す四角枠がドラッグ量に比例して小さくなっていくって感じでしたよね

でも結局実用的には、全体表示（又はジャンプ）して必要な部分を拡大 又は ホイールでの拡大縮小 で必要十分だと思いますけど


Indexへ
(3389)←【3391】→(3394)
------------------------
【タイトル】高橋さん、名無しさん。改善の余地について。
【記事番号】 3391 (3387)
【 日時 】05/09/15 17:09
【 発言者 】武蔵

▼高橋さん：レスありがとうございます。
>
>当方で要望を出すとすると、
>
>基本設定で指定した倍率で縮小する。
>
>という辺りになります。PageUpPageDownの設定の様にです。
>
>個人的には、もう少し余計に縮小したくて、という理由です。
>
>現状当方の操作は、拡大はドラッグ、縮小はスクロールになっています。
>
・・・中略
>
>縮小率について、厳密に指定（いろいろな方法で）できたとしても
>
>変化の状態が思ったほどではない、のではないか、というのが私の予想で、
>
>過度に縮小して、拡大し直すというのが、簡便になればと思っております。
>
>
>ちなみにDOS版の時は、小さく動かすと過度に縮小され、
>
>大きく動かすと少しだけ縮小されていました。
>
>武蔵さんが今回思ったのと逆の動きでしょうか。
>
>

　私が今回思ったのは、縮小するときは両ボタンドラッグでもホイール操作のように
拡大・縮小できたら便利だと思いました。
　ＪＷＣＡＤやＪＷＷＩＮの両ボタンドラッグの縮小では縮小された結果が表示される
までどのくらい縮小されるかが視覚的にわからないので、両ボタンドラッグでもホイー
ル操作のように拡大・縮小できたら便利だと思いました。

----------------------------------------------------------------------

▼名無しさん：レスありがとうございます。


>　拡大の時はドラッグ量に比例しているのに、縮小の時は比率が一定なのは使用感とし
>て変だなとは思いますが、実用的には見えない部分を予想してドラッグ量を決めるのは
>意外と大変です

　両ボタンドラッグによる拡大縮小がホイールによる拡大・縮小のようになれば、視覚的
に縮小できるので便利だと思います。

>DOS版の縮小の時は今の表示範囲を示す四角枠がドラッグ量に比例して小さくなっていく
>って感じでしたよね

　上と同じになりますが、視覚的に縮小できなければ便利にはならないと思います。

>でも結局実用的には、全体表示（又はジャンプ）して必要な部分を拡大 又は ホイール
>での拡大縮小 で必要十分だと思いますけど

　たしかに、ＡＵＴＯＣＡＤなどに比べて、ＪＷＣＡＤの拡大縮小の操作性は一歩も二歩
も先んじていると思います。
　しかし、両ボタンドラッグによる拡大縮小がホイールによる拡大・縮小のようになれば、視覚的に縮小できるのでより便利になると思います。

------------------------------------------------------------

　最後になりますが、高橋さんは、

>現状当方の操作は、拡大はドラッグ、縮小はスクロールになっています。

　と、おっしゃております。これは、現状の仕様で、試行錯誤の末にたどりついた
操作方法だと思います。但し、裏を返せば両ボタンドラッグによる拡大・縮小に
改善の余地があることを表しているのではないのでしょうか。


Indexへ
(3391)←【3394】→(3400)
------------------------
【タイトル】Re(1):高橋さん、名無しさん。改善の余地について。
【記事番号】 3394 (3391)
【 日時 】05/09/15 18:18
【 発言者 】高橋

▼武蔵さん：
>　最後になりますが、高橋さんは、
>
>>現状当方の操作は、拡大はドラッグ、縮小はスクロールになっています。
>
>　と、おっしゃております。これは、現状の仕様で、試行錯誤の末にたどりついた
>操作方法だと思います。但し、裏を返せば両ボタンドラッグによる拡大・縮小に
>改善の余地があることを表しているのではないのでしょうか。

縮小　についてはそうであると思います。

当方の要望は、前出の

>>基本設定で指定した倍率で縮小する。
>>
>>という辺りになります。PageUpPageDownの設定の様にです

です。


>　私が今回思ったのは、縮小するときは両ボタンドラッグでもホイール操作のように
>拡大・縮小できたら便利だと思いました。
>　ＪＷＣＡＤやＪＷＷＩＮの両ボタンドラッグの縮小では縮小された結果が表示される
>までどのくらい縮小されるかが視覚的にわからないので、両ボタンドラッグでもホイー
>ル操作のように拡大・縮小できたら便利だと思いました。

ホイールも、縮小された結果であって、他のものではないと思いますが、

言いたいことは分かります。

まさにホイールやPageUpPageDownのようにカクカクした感じなら

あり得るのかもしれません。

当初のリアルタイムと言う言葉で危惧された事案はあるでしょうけれども。

ぱっと一足飛びに小さくなるのも必要なので、そこまでふくめないと何かが

無駄になりかねない・・


・・当方で縮小をスクロールを利用しているのは、決してすこしづつ縮小しようと

している訳でではなくむしろ一気に縮小するためです。次に拡大し直すためです。

スクロールの拡縮の割合は、PageUpPageDownの

拡大･縮小率の設定に連動していて、

数値を大きく設定すると一気に小さくなります。

それに対比して思っていたことです。


　　


Indexへ
(3394)←【3400】→(3403)
------------------------
【タイトル】現状との折り合いについて。
【記事番号】 3400 (3394)
【 日時 】05/09/16 06:30
【 発言者 】武蔵

▼高橋さん：レスありがとうございます。
>
>ぱっと一足飛びに小さくなるのも必要なので、そこまでふくめないと何かが
>
>無駄になりかねない・・
>
>
>・・当方で縮小をスクロールを利用しているのは、決してすこしづつ縮小しようと
>
>している訳でではなくむしろ一気に縮小するためです。次に拡大し直すためです。

　たしかに両ボタンドラッグの右上と左下の機能について無視しすぎた書き方でし
た。
　当然ですが、右上と左下は現状維持のつもりでおります。


>
>スクロールの拡縮の割合は、PageUpPageDownの
>
>拡大･縮小率の設定に連動していて、
>
>数値を大きく設定すると一気に小さくなります。
>
>それに対比して思っていたことです。
>

　両ボタンドラッグ右上の全体表示がなくなることを危惧されておられるのでしょ
うか、言葉が足りず申し訳ありませんでした。


Indexへ
(3400)←【3403】→(3405)
------------------------
【タイトル】両ボタンドラッグによる縮小について。
【記事番号】 3403 (3400)
【 日時 】05/09/16 09:28
【 発言者 】高橋

▼武蔵さん：
>▼高橋さん：レスありがとうございます。
>
>　たしかに両ボタンドラッグの右上と左下の機能について無視しすぎた書き方でし
>た。
>　当然ですが、右上と左下は現状維持のつもりでおります。
>
>
>
>　両ボタンドラッグ右上の全体表示がなくなることを危惧されておられるのでしょ
>うか、言葉が足りず申し訳ありませんでした。


私の話は左上だけの話で、その倍率だけの話です。

いろいろ説明したらややこしく感じましたでしょうか？

私の要望は、武蔵さんの要望とは　全く別ですが、

武蔵さんの要望を妨げる方向ではないと

当方は認識しているのですが・・・


　


Indexへ
(3403)←【3405】→(3418)
------------------------
【タイトル】両ボタンドラッグでも、ホイールによる拡大縮小のように、
【記事番号】 3405 (3403)
【 日時 】05/09/16 12:47
【 発言者 】武蔵

▼高橋さん：レスありがとうございます。

>私の話は左上だけの話で、その倍率だけの話です。
>
>いろいろ説明したらややこしく感じましたでしょうか？
>
>私の要望は、武蔵さんの要望とは　全く別ですが、
>
>武蔵さんの要望を妨げる方向ではないと
>
>当方は認識しているのですが・・・


　高橋さんは、前回このように発言されました。

>>ぱっと一足飛びに小さくなるのも必要なので、そこまでふくめないと何かが

>>無駄になりかねない・・


>>・・当方で縮小をスクロールを利用しているのは、決してすこしづつ縮小しようと

>>している訳でではなくむしろ一気に縮小するためです。次に拡大し直すためです。

　そこで、てっきり全体表示がなくなると困るのかと思いましたがどうやら違うようで
すね、確かに基本設定の拡大・縮小率を大きく設定すれば一足飛びに小さくなりますから
、ただこれについては発言済みですし、ホイールには実装済みの機能ですので考えすぎました。

↓ここで発言しています。
http://hpcgi2.nifty.com/jw_cad/c-board.cgi?cmd=one;no=3363;id=003

　私の発言での主題は、【両ボタンドラッグでも、ホイールによる拡大縮小のように、
視覚的に操作したい。】です。
　倍率については、両ボタンドラッグの縮小にも反映されると便利ですね、比較的早期
実現可能でもありそうですし。以上です。


Indexへ
(3405)←【3418】→(3421)
------------------------
【タイトル】Re(1):補足させていただきます。
【記事番号】 3418 (3387)
【 日時 】05/09/17 14:17
【 発言者 】denki

もし、ホイールを回す操作が軽減されれば良いのであれば、以下のマウスを使用されてはいかがでしょうか？くるくる回すより楽ですよ。少し高いのですが・・・慣れればすごく楽です。手首の負担も軽減されると思います。
もし、話の趣旨が違っていましたらお許しください。
（拡大縮小したいところを基点にスムーズに拡大縮小しますよ・・・jwwの拡大縮小率は1.1で使用しています。）
IBMのThinkPlus ３ボタン スクロールポイント マウス ＩＩ (オプティカル)です。中央のボタンを手前、奥、とほんの少し動かすだけでホイールを回す操作と同様になります。ホイールボタンを押して行う操作は、ボタンの奥の（左右ボタンの間の）ボタンを押します。


Indexへ
(3418)←【3421】→(3427)
------------------------
【タイトル】Re(2):補足させていただきます。
【記事番号】 3421 (3418)
【 日時 】05/09/17 18:35
【 発言者 】武蔵

▼denkiさん：レスありがとうございます。
>もし、ホイールを回す操作が軽減されれば良いのであれば、以下のマウスを使用されてはいかがでしょうか？くるくる回すより楽ですよ。少し高いのですが・・・慣れればすごく楽です。手首の負担も軽減されると思います。
>もし、話の趣旨が違っていましたらお許しください。
>（拡大縮小したいところを基点にスムーズに拡大縮小しますよ・・・jwwの拡大縮小率は1.1で使用しています。）
>IBMのThinkPlus ３ボタン スクロールポイント マウス ＩＩ (オプティカル)です。中央のボタンを手前、奥、とほんの少し動かすだけでホイールを回す操作と同様になります。ホイールボタンを押して行う操作は、ボタンの奥の（左右ボタンの間の）ボタンを押します。

http://hpcgi2.nifty.com/jw_cad/c-board.cgi?cmd=one;no=3387;id=003
　↑
　ご参照下さい。
　わがままに聞こえることとは存じますが、以前に、中央のボタンを手前、奥と動かす
タイプのマウスは使ってみましたが、イメージ通りに操作するのが難しいです。
　CADだけでなくwindows全体（ワード、エクセルなど）的に、ワンテンポ感覚がずれて
いる感じがするのです。
　あと、クリックは上、下に動く動作ですが、中央のボタンは手前、奥という動作になり
指の曲げ伸ばしの点からいうと、やはりクリックのように上、下の動作のほうが関節の
負担が少ないのです。

　ご親切に、ご提案ありがとうございました。
　


Indexへ
(3421)←【3427】→(3378)
------------------------
【タイトル】Re(1):ＥＤＧＥＳＷＥＥＰＥＲって
【記事番号】 3427 (3418)
【 日時 】05/09/18 11:40
【 発言者 】アイベル aiber@catv-mic.ne.jp

▼makumaさん：
　
　忙しい所ありがとうございます
ｲーﾒｼﾞｿﾌﾄにてｸﾞﾚをモノクロに変換して、EDGEAWEEPERＣソフトにて読込み可能

お蔭さまでした。　感謝致します。


Indexへ
(3427)←【3378】→(3381)
------------------------
【タイトル】マウスは動かすのですね
【記事番号】 3378 (3371)
【 日時 】05/09/15 01:18
【 発言者 】joker
【 リンク 】http://www.atsmile.com/jw/



▼武蔵さん：
>mousemoveイベントとマウスの移動量（相対位置）を演算することで対応可能かと思います。

マウスは動かすのですね。
であれば、イベントは発生しますから私の前発言は無視してください。

私は、左右ボタンを押したまま、マウスはじっとそのまま動かさず
カウントが増えるのを見て、ここだ、というときにボタンを離す、のかと
思いました。（そうすれば手首の負担は減るだろうから楽だ、というような
意味かと思いました）


Indexへ
(3378)←【3381】//(3385)
------------------------
【タイトル】マウスは動かします。
【記事番号】 3381 (3378)
【 日時 】05/09/15 07:06
【 発言者 】武蔵

▼jokerさん：レスありがとうございます。
>>mousemoveイベントとマウスの移動量（相対位置）を演算することで対応可能かと思います。
>
>マウスは動かすのですね。
>であれば、イベントは発生しますから私の前発言は無視してください。
>
>私は、左右ボタンを押したまま、マウスはじっとそのまま動かさず
>カウントが増えるのを見て、ここだ、というときにボタンを離す、のかと
>思いました。（そうすれば手首の負担は減るだろうから楽だ、というような
>意味かと思いました）

　いわんとしていることが伝わり安心しました。
　このやりとりでより多くの人に伝わればいいと思います。