CrystalDiskInfoやCrystalDiskMarkなどCrystal Dew World製品に関する総合掲示板です。
|
![[NEW]](./brd/myk/image/new_icon.gif){kind=icon}
ひよひよ
- 20/9/23(水) 0:50 -
|
▼G神さん：
ご指摘ありがとうございます。
影響範囲が小さくすぐに直せる部分は 8.x で修正しつつ、根本的には、9.xで改善を図りたいと思います。
ALARM_HISTORY機能を実装しようとちょっとやり始めたものの見送ったため、その残骸が残っていました。スペリングミスは想定外でしたが。
ご指摘ありがとうございます。
影響範囲が小さくすぐに直せる部分は 8.x で修正しつつ、根本的には、9.xで改善を図りたいと思います。
ALARM_HISTORY機能を実装しようとちょっとやり始めたものの見送ったため、その残骸が残っていました。スペリングミスは想定外でしたが。
|
G神
- 20/9/22(火) 21:01 -
|
以下、続きです。
現在、ユーザー定義メッセージが、
#define WM_THEME_ID (WM_APP + 0x0100) // 0x8000 + 0x0100 = 33024〜(33024+テーマ数-1)
#define WM_LANGUAGE_ID (WM_APP + 0x0200) // 0x8000 + 0x0200 = 33280〜(33280+言語数-1)
となっていますが、「resource.h」に登録されたメニューIDを見ると、この先テーマ数が増えた際、WM_LANGUAGE_IDの範囲と被るより前に、既存のメニューIDと被って思わずバグりそうなので、思い切って、WM_APP+0x200/WM_APP+0x300とかに直した方がよいと思います。
また、以下のID並びは「33127」が飛んでいます。
#define ID_AUTO_DETECTION_05_SEC 33125
#define ID_AUTO_DETECTION_10_SEC 33126
#define ID_AUTO_DETECTION_20_SEC 33128
#define ID_AUTO_DETECTION_30_SEC 33129
#define ID_AUTO_DETECTION_DISABLE 33130
CDiskInfoDlg::CheckRadioAutoDetection()内の処理、
pMenu->CheckMenuRadioItem(ID_AUTO_DETECTION_05_SEC,ID_AUTO_DETECTION_DISABLE,id,MF_BYCOMMAND);
で都合が悪いかもしれません。
似た処理はメニューID値(番号)を連続する値に割り当ててやれば、「ON_COMMAND_RANGE」マクロを使ってメッセージハンドラを共通化できますし、設定項目の追加や変更も容易です。
[.h ファイル]
class CDiskInfoDlg : public CMainDialogFx
{
// 中略
private:
static CONST INT s_intAutoDetectSetting[];
static CONST INT s_intAutoDetectChoice;
// 中略
protected:
afx_msg void OnAutoDetection(UINT nCommandID);
// 中略
};
[.cpp ファイル]
CONST INT CDiskInfoDlg::s_intAutoDetectSetting[]=
{5 /* [0]:ID_AUTO_DETECTION_05_SEC */
,10 /* [1]:ID_AUTO_DETECTION_10_SEC */
,20 /* [2]:ID_AUTO_DETECTION_20_SEC */
,30 /* [3]:ID_AUTO_DETECTION_30_SEC */
,0 /* [4]:ID_AUTO_DETECTION_DISABLE */ };
CONST INT CDiskInfoDlg::s_intAutoDetectChoice = _countof(s_intAutoDetectSetting);
ON_COMMAND_RANGE(ID_AUTO_DETECTION_05_SEC, ID_AUTO_DETECTION_DISABLE, &CDiskInfoDlg::OnAutoDetection)
void CDiskInfoDlg::OnAutoDetection(UINT nCommandID)
{
if(ID_AUTO_DETECTION_05_SEC<=nCommandID && nCommandID<=ID_AUTO_DETECTION_DISABLE)
{
int nIndex;
nIndex=nCommandID-ID_AUTO_DETECTION_05_SEC;
if(0<=nIndex && nIndex<s_intAutoDetectChoice)
CheckRadioWaitTime(nCommandID, s_intAutoDetectSetting[nIndex]);
else
ASSERT(FALSE); /* Short table entry or command rang is not match. */
}
else
{
TRACE(_T("\r\nERROR : Unknown ID=0x%08X, in %s"),nCommandID,_T(__FUNCTION__));
ASSERT(FALSE);
}
}
なお、念のため CDiskInfoDlg のコンストラクタ内にでも、以下のようなASSERTマクロを埋めておけば、
ASSERT( ID_AUTO_DETECTION_10_SEC == ID_AUTO_DETECTION_05_SEC + 1 );
ASSERT( ID_AUTO_DETECTION_20_SEC == ID_AUTO_DETECTION_10_SEC + 1 );
ASSERT( ID_AUTO_DETECTION_30_SEC == ID_AUTO_DETECTION_20_SEC + 1 );
ASSERT( ID_AUTO_DETECTION_DISABLE == ID_AUTO_DETECTION_30_SEC + 1 );
ASSERT((ID_AUTO_DETECTION_DISABLE - ID_AUTO_DETECTION_05_SEC + 1) == _countof(s_intAutoDetectSetting));
[1] IDがちゃんと並び順になっているかどうか
[2] ID範囲の個数とテーブルの要素数が一致しているか
を、Debugビルドの実行時にチェックできます。
※ ASSERTマクロは、Releaseビルド時のコード生成に影響を与えませんが、
関数の戻り値をチェックするのに、関数呼び出しをASSERTマクロで囲むと、
Releaseビルドで、関数の呼出(実行)も行われなくなるので、VERIFY()
マクロを使うか、戻り値を一旦変数に格納して、ASSERTマクロで変数の
値をチェックするようにしてください。
それから、DiskInfoDlgUpdate.cppの 1605行目 ...
cstr = i18n(_T("Menu"), _T("ALERM_HISTORY"));
ですが、
【誤】 ......「ALERM_HISTORY」
【正】 ......「ALARM_HISTORY」
だと思います。
現在「ID_ALARM_HISTORY」メニューは使われていないので実害はありませんが、綴りが違うので、言語ファイル(.lang)からの読み込みに失敗して i18n() から
空文字列("")が返されるとともに、「ID_ALARM_HISTORY」メニューは存在しないので、
menu->ModifyMenu(ID_ALARM_HISTORY, MF_STRING, ID_ALARM_HISTORY, cstr);
の呼び出しが失敗(戻り値がFALSE)になります。
関数の戻り値をチェックするように、ModifyMenuの呼び出しをVERIFY()マクロで囲んでやると、Debug/Releaseビルドとも、当該行でエラーが発生します。
最後に、これはご本人次第になりますが、逐次対応するのは大変だと思うので、致命的な不具合でもない限り、更新のリリースは月1回とか、2ヶ月に1回とかに限定した方がよくないですか？
以上、ご報告とご提案まで。
現在、ユーザー定義メッセージが、
#define WM_THEME_ID (WM_APP + 0x0100) // 0x8000 + 0x0100 = 33024〜(33024+テーマ数-1)
#define WM_LANGUAGE_ID (WM_APP + 0x0200) // 0x8000 + 0x0200 = 33280〜(33280+言語数-1)
となっていますが、「resource.h」に登録されたメニューIDを見ると、この先テーマ数が増えた際、WM_LANGUAGE_IDの範囲と被るより前に、既存のメニューIDと被って思わずバグりそうなので、思い切って、WM_APP+0x200/WM_APP+0x300とかに直した方がよいと思います。
また、以下のID並びは「33127」が飛んでいます。
#define ID_AUTO_DETECTION_05_SEC 33125
#define ID_AUTO_DETECTION_10_SEC 33126
#define ID_AUTO_DETECTION_20_SEC 33128
#define ID_AUTO_DETECTION_30_SEC 33129
#define ID_AUTO_DETECTION_DISABLE 33130
CDiskInfoDlg::CheckRadioAutoDetection()内の処理、
pMenu->CheckMenuRadioItem(ID_AUTO_DETECTION_05_SEC,ID_AUTO_DETECTION_DISABLE,id,MF_BYCOMMAND);
で都合が悪いかもしれません。
似た処理はメニューID値(番号)を連続する値に割り当ててやれば、「ON_COMMAND_RANGE」マクロを使ってメッセージハンドラを共通化できますし、設定項目の追加や変更も容易です。
[.h ファイル]
class CDiskInfoDlg : public CMainDialogFx
{
// 中略
private:
static CONST INT s_intAutoDetectSetting[];
static CONST INT s_intAutoDetectChoice;
// 中略
protected:
afx_msg void OnAutoDetection(UINT nCommandID);
// 中略
};
[.cpp ファイル]
CONST INT CDiskInfoDlg::s_intAutoDetectSetting[]=
{5 /* [0]:ID_AUTO_DETECTION_05_SEC */
,10 /* [1]:ID_AUTO_DETECTION_10_SEC */
,20 /* [2]:ID_AUTO_DETECTION_20_SEC */
,30 /* [3]:ID_AUTO_DETECTION_30_SEC */
,0 /* [4]:ID_AUTO_DETECTION_DISABLE */ };
CONST INT CDiskInfoDlg::s_intAutoDetectChoice = _countof(s_intAutoDetectSetting);
ON_COMMAND_RANGE(ID_AUTO_DETECTION_05_SEC, ID_AUTO_DETECTION_DISABLE, &CDiskInfoDlg::OnAutoDetection)
void CDiskInfoDlg::OnAutoDetection(UINT nCommandID)
{
if(ID_AUTO_DETECTION_05_SEC<=nCommandID && nCommandID<=ID_AUTO_DETECTION_DISABLE)
{
int nIndex;
nIndex=nCommandID-ID_AUTO_DETECTION_05_SEC;
if(0<=nIndex && nIndex<s_intAutoDetectChoice)
CheckRadioWaitTime(nCommandID, s_intAutoDetectSetting[nIndex]);
else
ASSERT(FALSE); /* Short table entry or command rang is not match. */
}
else
{
TRACE(_T("\r\nERROR : Unknown ID=0x%08X, in %s"),nCommandID,_T(__FUNCTION__));
ASSERT(FALSE);
}
}
なお、念のため CDiskInfoDlg のコンストラクタ内にでも、以下のようなASSERTマクロを埋めておけば、
ASSERT( ID_AUTO_DETECTION_10_SEC == ID_AUTO_DETECTION_05_SEC + 1 );
ASSERT( ID_AUTO_DETECTION_20_SEC == ID_AUTO_DETECTION_10_SEC + 1 );
ASSERT( ID_AUTO_DETECTION_30_SEC == ID_AUTO_DETECTION_20_SEC + 1 );
ASSERT( ID_AUTO_DETECTION_DISABLE == ID_AUTO_DETECTION_30_SEC + 1 );
ASSERT((ID_AUTO_DETECTION_DISABLE - ID_AUTO_DETECTION_05_SEC + 1) == _countof(s_intAutoDetectSetting));
[1] IDがちゃんと並び順になっているかどうか
[2] ID範囲の個数とテーブルの要素数が一致しているか
を、Debugビルドの実行時にチェックできます。
※ ASSERTマクロは、Releaseビルド時のコード生成に影響を与えませんが、
関数の戻り値をチェックするのに、関数呼び出しをASSERTマクロで囲むと、
Releaseビルドで、関数の呼出(実行)も行われなくなるので、VERIFY()
マクロを使うか、戻り値を一旦変数に格納して、ASSERTマクロで変数の
値をチェックするようにしてください。
それから、DiskInfoDlgUpdate.cppの 1605行目 ...
cstr = i18n(_T("Menu"), _T("ALERM_HISTORY"));
ですが、
【誤】 ......「ALERM_HISTORY」
【正】 ......「ALARM_HISTORY」
だと思います。
現在「ID_ALARM_HISTORY」メニューは使われていないので実害はありませんが、綴りが違うので、言語ファイル(.lang)からの読み込みに失敗して i18n() から
空文字列("")が返されるとともに、「ID_ALARM_HISTORY」メニューは存在しないので、
menu->ModifyMenu(ID_ALARM_HISTORY, MF_STRING, ID_ALARM_HISTORY, cstr);
の呼び出しが失敗(戻り値がFALSE)になります。
関数の戻り値をチェックするように、ModifyMenuの呼び出しをVERIFY()マクロで囲んでやると、Debug/Releaseビルドとも、当該行でエラーが発生します。
最後に、これはご本人次第になりますが、逐次対応するのは大変だと思うので、致命的な不具合でもない限り、更新のリリースは月1回とか、2ヶ月に1回とかに限定した方がよくないですか？
以上、ご報告とご提案まで。
|
G神
- 20/9/22(火) 20:56 -
|
現在公開されている最新の「8.8.7」で確認して、幾つか気がついた点があったのでまとめてご報告します。
まず、メインダイアログ(CDiskInfoDlg クラス)の以下の関数は、ボタン押下(BN_CLICKED)メッセージハンドラと思われますが、現在はコメントで書いた関数へ変更されており、中身は同じ処理ですが、こちらは現在使われていません。
宣言: DiskInfoDlg.h ............. 346行〜 356行
実装: DiskInfoDlgUpdate.cpp ..... 2214行〜2225行
void OnDisk0(); // Replaced! → afx_msg void OnBnClickedButtonDisk0();
void OnDisk1(); // Replaced! → afx_msg void OnBnClickedButtonDisk1();
void OnDisk2(); // Replaced! → afx_msg void OnBnClickedButtonDisk2();
void OnDisk3(); // Replaced! → afx_msg void OnBnClickedButtonDisk3();
void OnDisk4(); // Replaced! → afx_msg void OnBnClickedButtonDisk4();
void OnDisk5(); // Replaced! → afx_msg void OnBnClickedButtonDisk5();
void OnDisk6(); // Replaced! → afx_msg void OnBnClickedButtonDisk6();
void OnDisk7(); // Replaced! → afx_msg void OnBnClickedButtonDisk7();
void OnPreDisk(); // Replaced! → afx_msg void OnBnClickedButtonPreDisk();
void OnNextDisk(); // Replaced! → afx_msg void OnBnClickedButtonNextDisk();
void OnDiskStatus(); // Replaced! → afx_msg void OnBnClickedButtonHealthStatus();
※ CDiskInfoDlg::OnDiskStatus()は、CDiskInfoDlg::OnHealthStatus()を呼んでいますが、メッセージマップには、OnDiskStatus()と関連付けるエントリーがありません。
また、呼び出されているCDiskInfoDlg::OnHealthStatus()ですが、この関数の中身は、CDiskInfoDlg::OnBnClickedButtonHealthStatus()とまったく同じです。
前者の OnHealthStatus() は メニュー用のID = ID_HEALTH_STATUS ........................... 値:32982
後者の OnBnClickedButtonHealthStatus() は PUSHボタンのID = IDC_BUTTON_HEALTH_STATUS .... 値:1047
のメッセージハンドラとして登録されています。
ON_COMMAND(ID_HEALTH_STATUS, &CDiskInfoDlg::OnHealthStatus)
ON_BN_CLICKED(IDC_BUTTON_HEALTH_STATUS, &CDiskInfoDlg::OnBnClickedButtonHealthStatus)
(1) afx_msg void CDiskInfoDlg::OnHealthStatus()
宣言: DiskInfoDlg.h ............. 539行
実装: DiskInfoDlgMenu.cpp ....... 76行〜 84行
(2) afx_msg void CDiskInfoDlg::OnBnClickedButtonHealthStatus();
宣言: DiskInfoDlg.h ............. 581行
実装: DiskInfoDlg.cpp ........... 2395行〜2403行
また、以下の2つの関数は、関数名と返す値の型(int/DWORD)こそ違いますが、どちらも中身はメンバ変数「m_SelectDisk」の値を返していて同じ処理です。
後者はプログラム中で一切使われていません。
(1) ....... CDiskInfoDlg::GetSelectedDrive();
宣言: DiskInfoDlg.h ............. 384行
実装: DiskInfoDlgUpdate.cpp ..... 2227行〜2230行
(2) ....... DWORD CDiskInfoDlg::GetSelectDisk(); ← 使われていない
宣言: DiskInfoDlg.h ............. 103行
実装: DiskInfoDlg.cpp ........... 2303行〜2306行
ちなみに、クラスオブジェクトの内容を変更しない関数は、constを付ける習慣を付けた方が良いと思います。 参照やポインタで渡す引数についても、関数内で対象の引数の中身(文字列やオブジェクト)を変更しない場合についても同様です。
int CDiskInfoDlg::GetSelectedDrive();
↓
int CDiskInfoDlg::GetSelectedDrive() const;
文字数制限の為、投稿を分けます。
まず、メインダイアログ(CDiskInfoDlg クラス)の以下の関数は、ボタン押下(BN_CLICKED)メッセージハンドラと思われますが、現在はコメントで書いた関数へ変更されており、中身は同じ処理ですが、こちらは現在使われていません。
宣言: DiskInfoDlg.h ............. 346行〜 356行
実装: DiskInfoDlgUpdate.cpp ..... 2214行〜2225行
void OnDisk0(); // Replaced! → afx_msg void OnBnClickedButtonDisk0();
void OnDisk1(); // Replaced! → afx_msg void OnBnClickedButtonDisk1();
void OnDisk2(); // Replaced! → afx_msg void OnBnClickedButtonDisk2();
void OnDisk3(); // Replaced! → afx_msg void OnBnClickedButtonDisk3();
void OnDisk4(); // Replaced! → afx_msg void OnBnClickedButtonDisk4();
void OnDisk5(); // Replaced! → afx_msg void OnBnClickedButtonDisk5();
void OnDisk6(); // Replaced! → afx_msg void OnBnClickedButtonDisk6();
void OnDisk7(); // Replaced! → afx_msg void OnBnClickedButtonDisk7();
void OnPreDisk(); // Replaced! → afx_msg void OnBnClickedButtonPreDisk();
void OnNextDisk(); // Replaced! → afx_msg void OnBnClickedButtonNextDisk();
void OnDiskStatus(); // Replaced! → afx_msg void OnBnClickedButtonHealthStatus();
※ CDiskInfoDlg::OnDiskStatus()は、CDiskInfoDlg::OnHealthStatus()を呼んでいますが、メッセージマップには、OnDiskStatus()と関連付けるエントリーがありません。
また、呼び出されているCDiskInfoDlg::OnHealthStatus()ですが、この関数の中身は、CDiskInfoDlg::OnBnClickedButtonHealthStatus()とまったく同じです。
前者の OnHealthStatus() は メニュー用のID = ID_HEALTH_STATUS ........................... 値:32982
後者の OnBnClickedButtonHealthStatus() は PUSHボタンのID = IDC_BUTTON_HEALTH_STATUS .... 値:1047
のメッセージハンドラとして登録されています。
ON_COMMAND(ID_HEALTH_STATUS, &CDiskInfoDlg::OnHealthStatus)
ON_BN_CLICKED(IDC_BUTTON_HEALTH_STATUS, &CDiskInfoDlg::OnBnClickedButtonHealthStatus)
(1) afx_msg void CDiskInfoDlg::OnHealthStatus()
宣言: DiskInfoDlg.h ............. 539行
実装: DiskInfoDlgMenu.cpp ....... 76行〜 84行
(2) afx_msg void CDiskInfoDlg::OnBnClickedButtonHealthStatus();
宣言: DiskInfoDlg.h ............. 581行
実装: DiskInfoDlg.cpp ........... 2395行〜2403行
また、以下の2つの関数は、関数名と返す値の型(int/DWORD)こそ違いますが、どちらも中身はメンバ変数「m_SelectDisk」の値を返していて同じ処理です。
後者はプログラム中で一切使われていません。
(1) ....... CDiskInfoDlg::GetSelectedDrive();
宣言: DiskInfoDlg.h ............. 384行
実装: DiskInfoDlgUpdate.cpp ..... 2227行〜2230行
(2) ....... DWORD CDiskInfoDlg::GetSelectDisk(); ← 使われていない
宣言: DiskInfoDlg.h ............. 103行
実装: DiskInfoDlg.cpp ........... 2303行〜2306行
ちなみに、クラスオブジェクトの内容を変更しない関数は、constを付ける習慣を付けた方が良いと思います。 参照やポインタで渡す引数についても、関数内で対象の引数の中身(文字列やオブジェクト)を変更しない場合についても同様です。
int CDiskInfoDlg::GetSelectedDrive();
↓
int CDiskInfoDlg::GetSelectedDrive() const;
文字数制限の為、投稿を分けます。
|
G神
- 20/9/22(火) 20:51 -
|
▼金華山の仙人さん：
>このバグって、「俺環」「Win環」で解決保留？（困難？）になってる、下記の「JMicron/E9表示問題」や「CDIセーブ画像問題」に関係しそうでしょうか？
こんばんは。
指摘のバグは、SMART値のスレッショルドテーブルを出力するか否か、本来であれば「編集」-「コピーオプション」-「SMART_READ_THRESHOLD」メニューのチェックON/OFF状態に従うべきところを、「SMART_READ_DATA」チェック状態のON/OFFで判定しているというものです。
そのため「SMART_READ_DATA」がOFFの状態で、「SMART_READ_THRESHOLD」のみONにしても、スレッショルドテーブルはファイル出力等されず、「SMART_READ_DATA」がONの状態なら、「SMART_READ_THRESHOLD」のON/OFFに関係なく、スレッショルドテーブルが出力されるという動きになります。
それ以外の挙動に対しては、関係はないと思います。
ただ、気になったのが、プログラムの中核的なデータである、ATA_SMART_INFO を構造体として宣言していますが、コンストラクタが定義されていません。(Cと違いC++ではclassとstructはメンバのデフォルトの扱いがpublicか否かでほぼ同じ。class同様コンストラクタやデストラクタも定義できます)
そのためATA_SMART_INFO型の変数を使う都度、明示的に初期化しない限り、構造体メンバ変数の初期値が不定になるため、それが廻り廻って再現性のないバグの原因になっている可能性はあります。
ATA_SMART_INFO が構造体のままでも、とりあえずコンストラクタを定義することは可能です。 再現性のないバグを排除する目的なら、全てのメンバを自動で初期化するため、早急にコンストラクタを定義することと、併せて代入演算子(operator =)や、複製を作るコピーコンストラクタを定義した方がよいと思います。
あと気になったのは、APIの呼び出し結果をチェックせずにその後の処理を行っているとかですね。
APIによっては、特定条件下で呼び出した場合、必ず失敗するとかありますから。
>このバグって、「俺環」「Win環」で解決保留？（困難？）になってる、下記の「JMicron/E9表示問題」や「CDIセーブ画像問題」に関係しそうでしょうか？
こんばんは。
指摘のバグは、SMART値のスレッショルドテーブルを出力するか否か、本来であれば「編集」-「コピーオプション」-「SMART_READ_THRESHOLD」メニューのチェックON/OFF状態に従うべきところを、「SMART_READ_DATA」チェック状態のON/OFFで判定しているというものです。
そのため「SMART_READ_DATA」がOFFの状態で、「SMART_READ_THRESHOLD」のみONにしても、スレッショルドテーブルはファイル出力等されず、「SMART_READ_DATA」がONの状態なら、「SMART_READ_THRESHOLD」のON/OFFに関係なく、スレッショルドテーブルが出力されるという動きになります。
それ以外の挙動に対しては、関係はないと思います。
ただ、気になったのが、プログラムの中核的なデータである、ATA_SMART_INFO を構造体として宣言していますが、コンストラクタが定義されていません。(Cと違いC++ではclassとstructはメンバのデフォルトの扱いがpublicか否かでほぼ同じ。class同様コンストラクタやデストラクタも定義できます)
そのためATA_SMART_INFO型の変数を使う都度、明示的に初期化しない限り、構造体メンバ変数の初期値が不定になるため、それが廻り廻って再現性のないバグの原因になっている可能性はあります。
ATA_SMART_INFO が構造体のままでも、とりあえずコンストラクタを定義することは可能です。 再現性のないバグを排除する目的なら、全てのメンバを自動で初期化するため、早急にコンストラクタを定義することと、併せて代入演算子(operator =)や、複製を作るコピーコンストラクタを定義した方がよいと思います。
あと気になったのは、APIの呼び出し結果をチェックせずにその後の処理を行っているとかですね。
APIによっては、特定条件下で呼び出した場合、必ず失敗するとかありますから。
|
金華山の仙人
- 20/9/22(火) 14:57 -
|
▼ひよひよさん：
>ご連絡ありがとうございます。ご指摘の通り、m_bDumpSmartReadThresholdとすべき部分でした。
>
>次のバージョンで修正させていただきます。
このバグって、「俺環」「Win環」で解決保留？（困難？）になってる、下記の「JMicron/E9表示問題」や「CDIセーブ画像問題」に関係しそうでしょうか？
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1913;id=#1913
https://crystalmark.info/board/c-board.cgi?cmd=ntr;tree=1956
特定のDataが未設定になってる、ってのが、環境によって問題発生が変化するバグの原因として、結構怪しい気がしますが。
>ご連絡ありがとうございます。ご指摘の通り、m_bDumpSmartReadThresholdとすべき部分でした。
>
>次のバージョンで修正させていただきます。
このバグって、「俺環」「Win環」で解決保留？（困難？）になってる、下記の「JMicron/E9表示問題」や「CDIセーブ画像問題」に関係しそうでしょうか？
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1913;id=#1913
https://crystalmark.info/board/c-board.cgi?cmd=ntr;tree=1956
特定のDataが未設定になってる、ってのが、環境によって問題発生が変化するバグの原因として、結構怪しい気がしますが。
|
ひよひよ
- 20/9/22(火) 9:18 -
|
▼金華山の仙人さん：
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1964;id=#1964
>
>上記のSP600の場合と、完全に同様でOKでした。
>
>（今後の扱いも同様としたいと思います。）
ご確認ありがとうございました。
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1964;id=#1964
>
>上記のSP600の場合と、完全に同様でOKでした。
>
>（今後の扱いも同様としたいと思います。）
ご確認ありがとうございました。
|
ひよひよ
- 20/9/22(火) 9:16 -
|
▼金華山の仙人さん：
noMeiryoUI で私も同じように Yu Gothic UI 13ptに変更してみたのですが、再現しませんでした。
やっぱり本件は対応が難しそうです。
noMeiryoUI で私も同じように Yu Gothic UI 13ptに変更してみたのですが、再現しませんでした。
やっぱり本件は対応が難しそうです。
|
ひよひよ
- 20/9/22(火) 7:52 -
|
▼G神さん：
>CrystalDiskInfo 8.8.6 のソースコードについてお尋ねします。
>
>856行目:
>
>「m_bDumpSmartReadData」は、「m_bDumpSmartReadThreshold」の間違いでは
>ないかと思いますが、いかがでしょうか？
>
>【誤】
>-----------------
>> if(m_bDumpSmartReadData && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
>-----------------
>
>【正】
>-----------------
>> if(m_bDumpSmartReadThreshold && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
>-----------------
>
>SMART情報をファイルへ保存する処理が実装されている「DiskInfoDlgCopy.cpp」内の、CDiskInfoDlg::SaveText()メンバ関数内で、メンバ変数「m_bDumpSmartReadThreshold」
>を参照している部分がありません。
ご連絡ありがとうございます。ご指摘の通り、m_bDumpSmartReadThresholdとすべき部分でした。
次のバージョンで修正させていただきます。
>CrystalDiskInfo 8.8.6 のソースコードについてお尋ねします。
>
>856行目:
>
>「m_bDumpSmartReadData」は、「m_bDumpSmartReadThreshold」の間違いでは
>ないかと思いますが、いかがでしょうか？
>
>【誤】
>-----------------
>> if(m_bDumpSmartReadData && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
>-----------------
>
>【正】
>-----------------
>> if(m_bDumpSmartReadThreshold && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
>-----------------
>
>SMART情報をファイルへ保存する処理が実装されている「DiskInfoDlgCopy.cpp」内の、CDiskInfoDlg::SaveText()メンバ関数内で、メンバ変数「m_bDumpSmartReadThreshold」
>を参照している部分がありません。
ご連絡ありがとうございます。ご指摘の通り、m_bDumpSmartReadThresholdとすべき部分でした。
次のバージョンで修正させていただきます。
|
金華山の仙人 - 20/9/18(金) 20:59 - |
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1811;id=#1811
上記SG600の「WA値≒11.2」も酷かったけど、これはまあLAMDコン搭載初期のSSDなので、Firmwareの出来が悪かったと言えそうです。
WA値 = 総書き込み量(NAND)÷総書き込み量(ホスト) ≒ 4.56
〔14395GB〕 〔3160GB〕
しかしSX930は最新なSX950の、１世代前の製品なのに、此処迄酷いのは、かなり厳しいです。
まあ多分JMicron初の「pSCLキャッシュ方式」なFirmwareな筈なので、ノウハウが無かったせいだとは思いますが、SG600と同様にシステムドライブ(W10p64RS3)として使ってた為、今後は2D MLCのData保持力を活かして、データ保存用にする事にします。
上記SG600の「WA値≒11.2」も酷かったけど、これはまあLAMDコン搭載初期のSSDなので、Firmwareの出来が悪かったと言えそうです。
WA値 = 総書き込み量(NAND)÷総書き込み量(ホスト) ≒ 4.56
〔14395GB〕 〔3160GB〕
しかしSX930は最新なSX950の、１世代前の製品なのに、此処迄酷いのは、かなり厳しいです。
まあ多分JMicron初の「pSCLキャッシュ方式」なFirmwareな筈なので、ノウハウが無かったせいだとは思いますが、SG600と同様にシステムドライブ(W10p64RS3)として使ってた為、今後は2D MLCのData保持力を活かして、データ保存用にする事にします。
|
金華山の仙人 - 20/9/18(金) 13:59 - |
▼ひよひよさん：
>不思議な現象ですね。
>::PrintWindow() APIを呼び出してスクリーンショットを撮っているだけなので、GDIで描画しているオブジェクト自体が消えるということはどう解釈すれば良いのか・・・
>
>手元の環境では全く再現しませんし、直せない可能性もございます。
>当面、Alt + PrtSrc などでご対応いただければと。
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1965;id=#1965
上記にアップした様に、同じCDI8.8.6をW10p64/2004で実行したところ、SP600もSX930もCDIセーブした画像の右上表示は、消えませんでした。
「俺環」「Win環」等の影響がありそうな為、他ユーザーからの情報集まり待ちにして、個人的には終了にしたいと思います。
>不思議な現象ですね。
>::PrintWindow() APIを呼び出してスクリーンショットを撮っているだけなので、GDIで描画しているオブジェクト自体が消えるということはどう解釈すれば良いのか・・・
>
>手元の環境では全く再現しませんし、直せない可能性もございます。
>当面、Alt + PrtSrc などでご対応いただければと。
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1965;id=#1965
上記にアップした様に、同じCDI8.8.6をW10p64/2004で実行したところ、SP600もSX930もCDIセーブした画像の右上表示は、消えませんでした。
「俺環」「Win環」等の影響がありそうな為、他ユーザーからの情報集まり待ちにして、個人的には終了にしたいと思います。
|
金華山の仙人 - 20/9/18(金) 13:49 - |
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1964;id=#1964
上記のSP600の場合と、完全に同様でOKでした。
（今後の扱いも同様としたいと思います。）
上記のSP600の場合と、完全に同様でOKでした。
（今後の扱いも同様としたいと思います。）
|
金華山の仙人 - 20/9/18(金) 13:44 - |
CDI8.8.6がPC内に残ってた為、Diskinfo.ini等は初期化せず実行し、画像も下端をSMART項目最下行迄近づけて、CDIで画像セーブしてみました。
E9項目の表示も、セーブした画像もOKでした。(~_~;)
どちらも、ひよひよさんの方で原因不明な様ですし、これ以上「俺環」で確認しても、有用な情報が得られ無さそうな為、確認完了にしたいと思います。
（あとは、別ユーザーからの報告待ちで、多くのDataが集まってから、と言う事で。^^;）
E9項目の表示も、セーブした画像もOKでした。(~_~;)
どちらも、ひよひよさんの方で原因不明な様ですし、これ以上「俺環」で確認しても、有用な情報が得られ無さそうな為、確認完了にしたいと思います。
（あとは、別ユーザーからの報告待ちで、多くのDataが集まってから、と言う事で。^^;）
|
金華山の仙人 - 20/9/18(金) 13:19 - |
▼ひよひよさん：
>正直ソースコード上、翻訳した文字列を取得する部分にE9を特別扱いしているコードはありませんし、よくわからないです。
｜CrystalDiskInfo 8.8.6 リリース！
｜・Maxiotek SATA SSDコントローラー（MAS090X）対応
｜ （公式情報）
8.8.6 で上記MaxioTek（旧JMicron）対応の機能追加が入ったので、その影響が在りそうな気がします。
あとはバグ入りCDI8.8.xの動作確認ばかりしてるので、DiskInfo.ini にゴミや誤情報がまぎれたか、位でしょうか。
※とりあえず、この後W10p64/2004で最終確認してみます。
>正直ソースコード上、翻訳した文字列を取得する部分にE9を特別扱いしているコードはありませんし、よくわからないです。
｜CrystalDiskInfo 8.8.6 リリース！
｜・Maxiotek SATA SSDコントローラー（MAS090X）対応
｜ （公式情報）
8.8.6 で上記MaxioTek（旧JMicron）対応の機能追加が入ったので、その影響が在りそうな気がします。
あとはバグ入りCDI8.8.xの動作確認ばかりしてるので、DiskInfo.ini にゴミや誤情報がまぎれたか、位でしょうか。
※とりあえず、この後W10p64/2004で最終確認してみます。
|
G神 - 20/9/18(金) 6:41 - |
CrystalDiskInfo 8.8.6 のソースコードについてお尋ねします。
856行目:
「m_bDumpSmartReadData」は、「m_bDumpSmartReadThreshold」の間違いでは
ないかと思いますが、いかがでしょうか？
【誤】
-----------------
> if(m_bDumpSmartReadData && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
-----------------
【正】
-----------------
> if(m_bDumpSmartReadThreshold && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
-----------------
SMART情報をファイルへ保存する処理が実装されている「DiskInfoDlgCopy.cpp」内の、CDiskInfoDlg::SaveText()メンバ関数内で、メンバ変数「m_bDumpSmartReadThreshold」
を参照している部分がありません。
856行目:
「m_bDumpSmartReadData」は、「m_bDumpSmartReadThreshold」の間違いでは
ないかと思いますが、いかがでしょうか？
【誤】
-----------------
> if(m_bDumpSmartReadData && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
-----------------
【正】
-----------------
> if(m_bDumpSmartReadThreshold && (m_Ata.vars[i].DiskVendorId != m_Ata.SSD_VENDOR_NVME))
-----------------
SMART情報をファイルへ保存する処理が実装されている「DiskInfoDlgCopy.cpp」内の、CDiskInfoDlg::SaveText()メンバ関数内で、メンバ変数「m_bDumpSmartReadThreshold」
を参照している部分がありません。
|
ひよひよ
- 20/9/17(木) 23:37 -
|
▼ひよひよさん：
>▼金華山の仙人さん：
>>https://crystalmark.info/board/brd/myk/upload/1806_SeaTools-GUI_BarraCuda-SMART_1.PNG
>>
>>上記のSeaToolsで「UECC Error count」だった01項目が、一般的な「リードエラーレート」に戻ってて、間違いになってました。
>
>2つのシリーズをまとめたことが原因です。
>これ以上どうしようもないのでSeageteは3つに分割することにします。
CrystalDiskInfo 8.8.7では対応できなかったので、8.8.8で対応予定です。
>▼金華山の仙人さん：
>>https://crystalmark.info/board/brd/myk/upload/1806_SeaTools-GUI_BarraCuda-SMART_1.PNG
>>
>>上記のSeaToolsで「UECC Error count」だった01項目が、一般的な「リードエラーレート」に戻ってて、間違いになってました。
>
>2つのシリーズをまとめたことが原因です。
>これ以上どうしようもないのでSeageteは3つに分割することにします。
CrystalDiskInfo 8.8.7では対応できなかったので、8.8.8で対応予定です。
|
ひよひよ
- 20/9/16(水) 20:22 -
|
▼金華山の仙人さん：
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1929;id=#1929
>
>勇んで上記で頼まれた内容を実行しようと、CDI8.8.6をダウンロードしてSP600を試したところ、E9項目「総書き込み量(NAND)」表示がOKでした。
>ｽﾞｻｰｯε=ε=ε=c⌒っﾟДﾟ)っ
正直ソースコード上、翻訳した文字列を取得する部分にE9を特別扱いしているコードはありませんし、よくわからないです。
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1929;id=#1929
>
>勇んで上記で頼まれた内容を実行しようと、CDI8.8.6をダウンロードしてSP600を試したところ、E9項目「総書き込み量(NAND)」表示がOKでした。
>ｽﾞｻｰｯε=ε=ε=c⌒っﾟДﾟ)っ
正直ソースコード上、翻訳した文字列を取得する部分にE9を特別扱いしているコードはありませんし、よくわからないです。
|
ひよひよ
- 20/9/16(水) 20:20 -
|
▼金華山の仙人さん：
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1954;id=#1954
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1955;id=#1955
>
>上記２件のW10p64-1909での、CDIのセーブ機能による画像の、右上の表示が一部消えてたので、少し調べてみました。
>
>LCD画面上では消えておらず、SpinningToolによる画像セーブでは（当然？ながら）OKでした。
>
> ◇
>
>どうやらCDI画面の下端を、SMART項目表示の最下行に近づける程、右上の表示が消える量が増える様です。
>
>当面は運用で対処出来るでしょうが、先の２件の様に気付かずにUpされると、動作報告上困った事になる為、対処が必要だと思います。
不思議な現象ですね。
::PrintWindow() APIを呼び出してスクリーンショットを撮っているだけなので、GDIで描画しているオブジェクト自体が消えるということはどう解釈すれば良いのか・・・
手元の環境では全く再現しませんし、直せない可能性もございます。
当面、Alt + PrtSrc などでご対応いただければと。
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1954;id=#1954
>https://crystalmark.info/board/c-board.cgi?cmd=one;no=1955;id=#1955
>
>上記２件のW10p64-1909での、CDIのセーブ機能による画像の、右上の表示が一部消えてたので、少し調べてみました。
>
>LCD画面上では消えておらず、SpinningToolによる画像セーブでは（当然？ながら）OKでした。
>
> ◇
>
>どうやらCDI画面の下端を、SMART項目表示の最下行に近づける程、右上の表示が消える量が増える様です。
>
>当面は運用で対処出来るでしょうが、先の２件の様に気付かずにUpされると、動作報告上困った事になる為、対処が必要だと思います。
不思議な現象ですね。
::PrintWindow() APIを呼び出してスクリーンショットを撮っているだけなので、GDIで描画しているオブジェクト自体が消えるということはどう解釈すれば良いのか・・・
手元の環境では全く再現しませんし、直せない可能性もございます。
当面、Alt + PrtSrc などでご対応いただければと。
|
金華山の仙人 - 20/9/16(水) 6:16 - |
もしシステムクリーンアップが原因で、問題が解決したのなら、CDIプログラムの中で、何らかの初期化処理が抜けてる可能性が有るのでは？
そうだとしたら、今回は解決してるけど、多数のユーザーに幅広く使われ始めると、同じ問題が再発する懸念があるので要注意かと。
原因不明で解決した問題は、必ず原因不明で再発するので。
そうだとしたら、今回は解決してるけど、多数のユーザーに幅広く使われ始めると、同じ問題が再発する懸念があるので要注意かと。
原因不明で解決した問題は、必ず原因不明で再発するので。
|
金華山の仙人 - 20/9/16(水) 4:47 - |
尚、画面解像度は100%のデフォルトで行ってますが、システムフォントはnoMeiryoUI240.1を使って、13pointに拡大してます。
当初は削除されてたが暫く前からW10の標準機能でも、システムフォント拡大が可能になってますが、そちらを使うと不必要な箇所のフォントも拡大されてしまって却って見づらくなる為、未だにnoMeiryoUI240.1を使ってます。
尚、このnoMeiryoUI240.1が拡大するフォントは、どうやらW8.1迄に搭載されてた拡大機能の対象と、一致させてる感じです。
当初は削除されてたが暫く前からW10の標準機能でも、システムフォント拡大が可能になってますが、そちらを使うと不必要な箇所のフォントも拡大されてしまって却って見づらくなる為、未だにnoMeiryoUI240.1を使ってます。
尚、このnoMeiryoUI240.1が拡大するフォントは、どうやらW8.1迄に搭載されてた拡大機能の対象と、一致させてる感じです。
|
金華山の仙人 - 20/9/16(水) 4:14 - |
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1954;id=#1954
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1955;id=#1955
上記２件のW10p64-1909での、CDIのセーブ機能による画像の、右上の表示が一部消えてたので、少し調べてみました。
LCD画面上では消えておらず、SpinningToolによる画像セーブでは（当然？ながら）OKでした。
◇
どうやらCDI画面の下端を、SMART項目表示の最下行に近づける程、右上の表示が消える量が増える様です。
当面は運用で対処出来るでしょうが、先の２件の様に気付かずにUpされると、動作報告上困った事になる為、対処が必要だと思います。
https://crystalmark.info/board/c-board.cgi?cmd=one;no=1955;id=#1955
上記２件のW10p64-1909での、CDIのセーブ機能による画像の、右上の表示が一部消えてたので、少し調べてみました。
LCD画面上では消えておらず、SpinningToolによる画像セーブでは（当然？ながら）OKでした。
◇
どうやらCDI画面の下端を、SMART項目表示の最下行に近づける程、右上の表示が消える量が増える様です。
当面は運用で対処出来るでしょうが、先の２件の様に気付かずにUpされると、動作報告上困った事になる為、対処が必要だと思います。
