私もATOK2016を使っていますが、こちらの環境では不具合が再現できませんでした。

　Windows10 Pro 14393 64bit 、HAMLOG Ver. 5.26 2016/09/04 です。

　何が影響しているんでしょうかね。

> Windows10上でIMEをATOK2016にして，Hamlogを使っています．
>
> いままで感じた事が無かったのですが，
> 入力変換後（画像上段）すぐに再変換をかけると，未確定の文字列の位置がおかしくなります（画像中段）．
> それで変換して確定した結果が画像下段です．
> 半角，全角ともおかしくなります．
>
> 気がついたのは今回が初めてですが，よく使っていた以前は，全く気になりませんでした．
>
> そｊこで，以前のバージョンということで，適当に Ver5.25 Build A;pr-03 をインストールしてやってみたら，全く正常でした．
>
> ちなみにATOK以外のIME．．．MS-IME と GoogleIME は両方とも正常でした．
> また，この投稿文はGoogleChromeとATOKを使って，再変換を多用していますが，全く問題ありません．

JR0QCP さん，
情報ありがとうございます．

> 　私もATOK2016を使っていますが、こちらの環境では不具合が再現できませんでした。
>
> 　Windows10 Pro 14393 64bit 、HAMLOG Ver. 5.26 2016/09/04 です。

Windows10 Home ver.15.11 build 0586.545 です．

ATOK は，ver.29.02 でした．すっかり自動アップデートに慣れてしまったので気がつきませんでしたが，HPで確認して，現在は ver29.06 でしたので，アップデートしました．

が，状況は変わらずです．

> 　何が影響しているんでしょうかね。

ほんとに．不可解です．

【2016/09/10(Sat) 20:02:11 投稿者により修正されました。】

>
> > 　何が影響しているんでしょうかね。
>
> ほんとに．不可解です．
ＡＴＯＫ　3015　でも　Ｍｓ　ＩＭＥでも　川辺さんと同じように入力してみると
INS　の時は問題無いようですが、上書き　では次の半角が消えていくのですがこのことでしょうか
半角・全角（今こんな事言わないかな）の境界の問題は複雑ですから、文字化けしないだけ立派では

【2016/09/11(Sun) 11:53:24 投稿者により修正されました。】

> >
> > > 　何が影響しているんでしょうかね。
> >
> > ほんとに．不可解です．
> ＡＴＯＫ　3015　でも　Ｍｓ　ＩＭＥでも　川辺さんと同じように入力してみると
> INS　の時は問題無いようですが、上書き　では次の半角が消えていくのですがこのことでしょうか
> 半角・全角（今こんな事言わないかな）の境界の問題は複雑ですから、文字化けしないだけ立派では

上書きでは無く，Ins と表示されているときに起こっているのです．
テキストボックスが Windows32API のテキストボックスの標準の動作で起こっているとすると，
全てのテキストボックスで同じことが起こる（現在書き込み中のメッセージ欄とか）はずなのですが，
起こるのがHamlogだけ，しかも私の環境だけ，というのは困ったものです．

Just SYSTEMに相談するにできず．．．

> テキストボックスが Windows32API のテキストボックスの標準の動作で起こっているとすると，
> 全てのテキストボックスで同じことが起こる（現在書き込み中のメッセージ欄とか）はずなのですが，
> 起こるのがHamlogだけ，しかも私の環境だけ，というのは困ったものです．

色々なアプリケーションでやってみているのですが，私がVisual Basic 6.0で作成したソフトの，
TextBoxコントロールで再現性がありました．

VisualBasiv6.0という古い開発環境ですが，Win32APIの仕様が変わらない限り昔も今も同じように使えるはずですが．．．
Hamlogの方も，この辺はHamlog側では何もやっておらず，WindowsシステムとATOKとのやり取りで再変換がおこなわれているはずですよね．

> Just SYSTEMに相談するにできず．．．

とりあえず，自分のVB6ソフトで Just SYSTEM に相談してみることにします．

【2016/09/16(Fri) 09:12:30 投稿者により修正されました。】

> VisualBasiv6.0という古い開発環境ですが，Win32APIの仕様が変わらない限り昔も今も同じように使えるはずですが．．．
> Hamlogの方も，この辺はHamlog側では何もやっておらず，WindowsシステムとATOKとのやり取りで再変換がおこなわれているはずですよね．

Shift-JISだとうまく動作しない、ってことありえますか？

> > VisualBasiv6.0という古い開発環境ですが，Win32APIの仕様が変わらない限り昔も今も同じように使えるはずですが．．．
> > Hamlogの方も，この辺はHamlog側では何もやっておらず，WindowsシステムとATOKとのやり取りで再変換がおこなわれているはずですよね．
>
> Shift-JISだとうまく動作しない、ってことありえますか？

どうなんでしょうか．あまり文字の種類は考えたこと無いですが．．．
VBの場合は，見かけ上Shift-JISのように振る舞っていますが，
内部ではUniCodeで扱っているのではなかったかと思います．

すみません，あまり考えたこと無かったので．

> 上書きでは無く，Ins と表示されているときに起こっているのです．

上書きモードのときは、１文字入力があったらカーソル位置の１文字を削除すること
により、上書きを実現してます。

挿入モードのときは何もせず、上の方にInsと表示させているだけです。

> > 上書きでは無く，Ins と表示されているときに起こっているのです．
>
> 上書きモードのときは、１文字入力があったらカーソル位置の１文字を削除すること
> により、上書きを実現してます。
>
> 挿入モードのときは何もせず、上の方にInsと表示させているだけです。

なるほど，了解です．
実は，Insの時は問題ありですが，上書きの場合には問題が起こりません．
[上書きの場合]
一千二百三十四　 （確定）
↓再変換中↓
1234十四　　　　　　（1234はハイライト）
↓確定↓
1234

[Insの場合] （１２の入力でやります）
１２
１２２
１２２２
１１２２２
１１２２２２
１１１２２２２
・・・
と怪しいことになります．

KeyDownをトラップしていると問題があるかと思って，VB6で単にTextBoxコントロールを置いただけのプログラムを作ってみましたが，何もトラップしない場合でも同じ事が起こります．

こんなことになるのは私だけですよね．．．

> いままで感じた事が無かったのですが，
> 入力変換後（画像上段）すぐに再変換をかけると，未確定の文字列の位置がおかしくなります（画像中段）．
> それで変換して確定した結果が画像下段です．
> 半角，全角ともおかしくなります．

この異常動作，ATOKのアップデート（2016/09/06版；at29up4x64.exe）の再インストールと，Windowsの Panasonic driver update for System Interface Device で，正常に動作できるようになりました．どっちが正解だったのか．．．
後者の後の再起動直後に，Google Chromeを立ち上げて，Atokのアップで0との話を見て，あわてて前者をアップデートしたので，確かめ忘れました．

お騒がせしましてすみませんでした．

【2016/10/11(Tue) 12:58:35 投稿者により修正されました。】