私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.114 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
あるブログのコードを引用してここで質問したら
そのブログは転載とみなされて訴えられちゃうケース
そのブログは転載とみなされて訴えられちゃうケース
>>395
誰がどういう理由で訴えるのかを書かないのはなぜですか?
誰がどういう理由で訴えるのかを書かないのはなぜですか?
>>404はRaceqeen incが西村博之を訴えるという話でしょ
利用者に同影響するというのか?
利用者に同影響するというのか?
>>406
誰がどういう理由で訴えるのかを書かないのはなぜですか?
誰がどういう理由で訴えるのかを書かないのはなぜですか?
文字列が書かれたdivがあり、そのdivの中のどこかがクリックされた時
何列目の何行目をクリックされたか知るには
どうすればいいと思いますか?
何列目の何行目をクリックされたか知るには
どうすればいいと思いますか?
>>409
等幅フォントを指定し、マウス座標から該当文字位置を算出する
等幅フォントを指定し、マウス座標から該当文字位置を算出する
>>411
それだけだと行数を計測できないのでは?
それだけだと行数を計測できないのでは?
「先頭文字から座標を取得して行き」というけど
spanで区切らないと一列目以降の座標は取得できないのでは?
spanで区切らないと一列目以降の座標は取得できないのでは?
3行以内の質問は回答があっても大抵無反応だな
熱意ある回答者がいなくなるのもわかる気がする
熱意ある回答者がいなくなるのもわかる気がする
>>409
CaretPosition インタフェース(CSSOM)を使うか
上手くいくかどうか判らんし CaretPosition が未サポートかもしれないが
mousedown イベントの時点で contentEditable にしてから
click の時点で caret 位置を取得してごにょごにょ
CaretPosition インタフェース(CSSOM)を使うか
上手くいくかどうか判らんし CaretPosition が未サポートかもしれないが
mousedown イベントの時点で contentEditable にしてから
click の時点で caret 位置を取得してごにょごにょ
「今押されたキーのキーコード」 ではなく
「すでに押されてるキーのキーコード」 を
知る方法を知りたい。
「すでに押されてるキーのキーコード」 を
知る方法を知りたい。
「すでに押されてる」って?
今押されたのを覚えとけばイイとかって話じゃなく?
今押されたのを覚えとけばイイとかって話じゃなく?
keydownとkeyupを管理して
現在押されているキーコードの一覧が分かるようにしたらいいのでは
現在押されているキーコードの一覧が分かるようにしたらいいのでは
回答ありがとうございます
CaretPositionインタフェイスっていうのあるのですね
たしかにこのあたりの操作のしにくさは異常だと思っていました
ただまだ普及していないようなので
span区切りで座標データ化してポジショニングしようと思います
ありがとうございました
CaretPositionインタフェイスっていうのあるのですね
たしかにこのあたりの操作のしにくさは異常だと思っていました
ただまだ普及していないようなので
span区切りで座標データ化してポジショニングしようと思います
ありがとうございました
>>409 自分が過去にやった方法だと
まずdivを複製する、そのときにそのdivに間接的にかかってるスタイルを属性で直接指定する
次にouterHTMLをforeignObjectでくるんだSVGを作る
この時に最終文字の次スペースにマーカーに当たる要素置いて相対位置("左下")を取得しておく
そしてDataURLなんかでCanvasに貼り付ける
ここまでが基本の1操作
この基本の1操作を、div内の文字数を0からlengthまで変えながら試す↓
クリックされた相対位置がマーカー位置より前("左下"より左上)に初めてなった時の文字列の最終文字がクリックされた文字
もしくは極稀に起こるマーカーのみの改行に対処したり、0→lengthでないアルゴリズムにしたいときは、
クリックされた相対位置がマーカー位置より前("左下"より左上、または"左上"より上)になる最短の文字列の最終文字がクリックされた文字
画像が入ってたりするときは、ちょっとややこしい
一応SVGの画像もオリジンが継承されるようになってきたけど、
ブラウザやバージョンによってはオリジンエラーになることがある
そういう場合は画像をrectでもなんでもいいけど置き換える
いっそChromeが対応してるRTCでのスクリーンキャプチャで画像解析してもいいかもしれない
特色のマーカーを配置しておけばImageDataの解析は難しくないはず
まずdivを複製する、そのときにそのdivに間接的にかかってるスタイルを属性で直接指定する
次にouterHTMLをforeignObjectでくるんだSVGを作る
この時に最終文字の次スペースにマーカーに当たる要素置いて相対位置("左下")を取得しておく
そしてDataURLなんかでCanvasに貼り付ける
ここまでが基本の1操作
この基本の1操作を、div内の文字数を0からlengthまで変えながら試す↓
クリックされた相対位置がマーカー位置より前("左下"より左上)に初めてなった時の文字列の最終文字がクリックされた文字
もしくは極稀に起こるマーカーのみの改行に対処したり、0→lengthでないアルゴリズムにしたいときは、
クリックされた相対位置がマーカー位置より前("左下"より左上、または"左上"より上)になる最短の文字列の最終文字がクリックされた文字
画像が入ってたりするときは、ちょっとややこしい
一応SVGの画像もオリジンが継承されるようになってきたけど、
ブラウザやバージョンによってはオリジンエラーになることがある
そういう場合は画像をrectでもなんでもいいけど置き換える
いっそChromeが対応してるRTCでのスクリーンキャプチャで画像解析してもいいかもしれない
特色のマーカーを配置しておけばImageDataの解析は難しくないはず
SVGもキャンバスも使ったことないのでちょっと分からないですが
色んなやり方があるんですね
いつか使ってみたいと思います
ありがとうございました
色んなやり方があるんですね
いつか使ってみたいと思います
ありがとうございました
try/catchについて質問です
これまでは聞き齧った知識で漠然と
「tryブロック内の処理は遅くなる」
と思っていたのですが、実際は
「条件分岐として使うにはエラーキャッチ時の速度に難がある」
程度だという認識で正しいのでしょうか
これまでは聞き齧った知識で漠然と
「tryブロック内の処理は遅くなる」
と思っていたのですが、実際は
「条件分岐として使うにはエラーキャッチ時の速度に難がある」
程度だという認識で正しいのでしょうか
計測もしないで、速度を気にするやつは馬鹿である。
0.001秒のために、何時間も頑張る奴は仕事の優先順位がつけられない。
という認識でいいよw
0.001秒のために、何時間も頑張る奴は仕事の優先順位がつけられない。
という認識でいいよw
速度に難があると言ってる時点でなぁー
技術ってのは適切な場所に使うもので
速度のこと何って考えるのは最後の最後。
try/catchはtry/catchを使うべき所に使うもの。
速度に難とかを考える事自体が間違っている。
まあ多分、どういう所に使うかが
わかってないんだろうねー。勉強しろ。
技術ってのは適切な場所に使うもので
速度のこと何って考えるのは最後の最後。
try/catchはtry/catchを使うべき所に使うもの。
速度に難とかを考える事自体が間違っている。
まあ多分、どういう所に使うかが
わかってないんだろうねー。勉強しろ。
A級以上のプログラマは速度のことも常に気にしているもの
速度を気にするなとかいうのはB級のたわごと
速度を気にするなとかいうのはB級のたわごと
だから、速度のことを気にするのは、最後って言ってるだろ
頭悪いのか? 目が悪いのか? 顔が悪いのか? 全部か。
頭悪いのか? 目が悪いのか? 顔が悪いのか? 全部か。
処理ごとのコストは知らないより知っていた方がいいに決まってるのに
速度否定厨は知ること自体を否定するからな。
「些細なチューンのために何時間もかけるのは愚か」などと
勝手に前提を付け加えてそれを否定するのは馬鹿に共通する特徴。
自分で作った藁人形を突き刺してるにすぎないのだ。
速度否定厨は知ること自体を否定するからな。
「些細なチューンのために何時間もかけるのは愚か」などと
勝手に前提を付け加えてそれを否定するのは馬鹿に共通する特徴。
自分で作った藁人形を突き刺してるにすぎないのだ。
俺は質問者じゃねーから。
それに質問に計測は必須ではない。
答えたくなければスルーすればいい。
書かれてもいない条件を勝手に付加して否定するお前が馬鹿ということだけが真。
それに質問に計測は必須ではない。
答えたくなければスルーすればいい。
書かれてもいない条件を勝手に付加して否定するお前が馬鹿ということだけが真。
>>438
質問者じゃないのになんでレスしたんですか?
私は、レスした人(つまりあなた)に、レスしただけで
別に質問者にレスしたんじゃありませんよ
計測しないで速度云々言い出す奴は初心者。
そのことに何も違いはありませんが。
質問者じゃないのになんでレスしたんですか?
私は、レスした人(つまりあなた)に、レスしただけで
別に質問者にレスしたんじゃありませんよ
計測しないで速度云々言い出す奴は初心者。
そのことに何も違いはありませんが。
まーた「質問者じゃないとレスしてはいけない」
という謎の前提を付け加えて否定してる
質問には実行される頻度などについての条件は何も書かれていないのに
「数回しか実行しない」などという前提を付け加えるのと同様の愚を犯している。
問題の切り分け能力が低いんだよ
言葉の使い方だけで技術者としてのレベルの低さが分かる
という謎の前提を付け加えて否定してる
質問には実行される頻度などについての条件は何も書かれていないのに
「数回しか実行しない」などという前提を付け加えるのと同様の愚を犯している。
問題の切り分け能力が低いんだよ
言葉の使い方だけで技術者としてのレベルの低さが分かる
>>440
へ? だから俺もお前にレスしてるんだけど?
誰にレスしようが自由だろ。
try-catchは例外なんだから
実行される回数は少ないに決まってるだろ
それともお前が「多いって決めつける」のか?
お前実践経験ないんじゃね?
答えられる奴が実行回数答えろよ。
答えない限り、少ないという一般的な前提を当てはめるだけのこと。
あと、これは質問者にレスしてるんで、
お前はレスしなくていいよw
へ? だから俺もお前にレスしてるんだけど?
誰にレスしようが自由だろ。
try-catchは例外なんだから
実行される回数は少ないに決まってるだろ
それともお前が「多いって決めつける」のか?
お前実践経験ないんじゃね?
答えられる奴が実行回数答えろよ。
答えない限り、少ないという一般的な前提を当てはめるだけのこと。
あと、これは質問者にレスしてるんで、
お前はレスしなくていいよw
速度についてはアルゴリズムがO(n^2)になってないかを気にしていればいい
例えば、n個入力がある時に1個追加する度に全データを線形にサーチしちゃったり
しないように気を付ける
それがA級プログラマ
それ以外のどうでもいい高速化は考えるだけ無駄
直感的に分かりやすいように書けばいい
そんで最後にプロファイラで計測して遅くなってるところだけ直す
例えば、n個入力がある時に1個追加する度に全データを線形にサーチしちゃったり
しないように気を付ける
それがA級プログラマ
それ以外のどうでもいい高速化は考えるだけ無駄
直感的に分かりやすいように書けばいい
そんで最後にプロファイラで計測して遅くなってるところだけ直す
>>432-433に同意。
try-catchは使わなければ対応出来ない状況で使うべきで速度を考えるのはtry-catchを使わなければならないにも関わらず、十分なパフォーマンスを得られない場合。
実際、try-catchを使わなければならない状況はそれ程多くないはず。
それでも重くなるなら結果をキャッシュしておくとか、アルゴリズムを見直した方がいい。
try-catchは使わなければ対応出来ない状況で使うべきで速度を考えるのはtry-catchを使わなければならないにも関わらず、十分なパフォーマンスを得られない場合。
実際、try-catchを使わなければならない状況はそれ程多くないはず。
それでも重くなるなら結果をキャッシュしておくとか、アルゴリズムを見直した方がいい。
聞かれた質問に対してのみ答えればよろしい
その他のチューン云々の分かりきったグダ話はいらない
質問者の立場の時、この種のわかりきった説教ほどウザいものはない
そんなこと聞いてねえっつーの
その他のチューン云々の分かりきったグダ話はいらない
質問者の立場の時、この種のわかりきった説教ほどウザいものはない
そんなこと聞いてねえっつーの
あまりにも理解が表層的だからつっこまれてるの分からないの?
だからバカだのチョンだの言われるんだよw
だからバカだのチョンだの言われるんだよw
やっぱりネトウヨかw
相手の言葉に勝手に条件を付加して
自分の作りあげた藁人形を攻撃する論法がネトウヨくせーと思ってたわ
相手の言葉に勝手に条件を付加して
自分の作りあげた藁人形を攻撃する論法がネトウヨくせーと思ってたわ
バカは思考回路がショートしてるから人にレッテル貼って安心するんだよね
便利な言葉だよねネトウヨってwww
便利な言葉だよねネトウヨってwww
技術者に問われるのはいかに現実と向き合うかなので
現実逃避に酔いしれるネトウヨは致命的。
ネトウヨ的思考習慣は技術者としての精度を著しく下げてしまう
A級以上になりたければネトウヨを卒業することだな
現実逃避に酔いしれるネトウヨは致命的。
ネトウヨ的思考習慣は技術者としての精度を著しく下げてしまう
A級以上になりたければネトウヨを卒業することだな
思考が停止した奴に限って速度速度言うんだよ、計測しやすいからね
本来速度を改善することで得られるものは何なのかを明確にしなければただのオナニーなのに
だから技術者に求められるのは現実と向き合うなんて頭の悪いことを堂々と言えちゃうんだよね
本来速度を改善することで得られるものは何なのかを明確にしなければただのオナニーなのに
だから技術者に求められるのは現実と向き合うなんて頭の悪いことを堂々と言えちゃうんだよね
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.104 + (1001) - [97%] - 2013/1/28 4:00
- + JavaScript の質問用スレッド vol.124 + (1001) - [97%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
トップメニューへ / →のくす牧場書庫について