今回のまとめ

みなさん、こんにちは。Dr.テトランです。

前回の「簡易複合単価機能」は、如何でしたでしょうか。

この間、インサイド・オブ・テトラの追加記事を、微力ながら書き続けてはいるのですが、なかなかリリースには程遠い状態です。

そこで、その中の一つである「合成品の階層構造について」を、リークしたいと思います。

≪ はじめに ≫
当初、合成品は「９階層目の工事フォルダ」として導入されました。
但し、工事フォルダと異なって、内訳明細行と混在可能なように、終端行を持ちます。
つまり、工事フォルダから見ると、閉じた合成品フォルダは、明細行と同じです。
しかしながら、違いもあります。
一行の明細行には、各種分類値が一つづつですが、合成品では違います。
この違いは、計算式中の、分類に依存する値に、複雑な影響を及ぼします。
最新のTetra21システムでは、この合成品に階層構造を持ち込み、更に複雑化を増しています。
（階層とは、合成品内訳の要素として、別の合成品を許すことです。）
こうして生成された階層化合成品を、どの様に扱っているか、見てみましょう。

この序文以下、三つの章から成ります。

１．工事フォルダと合成品フォルダの違い

２．合成品の表示法

３．旧バージョンとの互換性

興味の有る方は、ここをクリックしてください。

みなさん、こんにちは。Dr.テトランです。

前回の投稿から、一年余りが過ぎてしまいました。前回の「複合単価を作成する」コマンドの一般化も進み、資料もほぼ完成したので、改めてリリースしたいと思います。基本的には、事後に行う按分処理の章を加えただけですが、齟齬があるといけないので、更新ではなく改めて発表します。

前回と同様に、この資料(PDF)は、Tetra21にある「複合単価を作成する」コマンドを内側から明かすことで、Tetra21をお使いの皆様（ユーザー）に正しい使い方を促す為のものです。また、これから、「Tetra21の簡易複合単価機能を使ってみようか？」と検討されているお客様においても、本コマンドを利用する価値があるか否かの判断にご活用ください。 なお、ドキュメントは、つぎの６つの項に分けて記載してあります。 （１と２は前回のまま、３は若干添削、４以降は追加した章です。）

１．理論的根拠
２．Tetra21での旧来の取り組み（モード０～３）
３．Tetra21での新しい取り組み（モード８～１５）
４．手動による按分指示（モード８・９）
５．各行の按分指示による（モード１０～１５）
６．今後の課題

興味の有る方は、ここをクリックしてください。

みなさん、こんにちは。Dr.テトランです。

この資料(PDF)は、Tetra21にある「複合単価を作成する」コマンドを内側から明かすことで、Tetra21をお使いの皆様（ユーザー）に正しい使い方を促す為のものです。

また、これから、「Tetra21の簡易複合単価機能を使ってみようか？」と検討されているお客様においても、本コマンドを利用する価値があるか否かの判断にご活用ください。

なお、ドキュメントは、つぎの４つの項に分けて記載してあります。

１．理論的根拠

２．Tetra21での旧来の取り組み

３．Tetra21での新しい取り組み

４．今後の課題

興味の有る方は、ここをクリックしてください。

皆さん、こんにちは。Dr.テトランです。
前回のエントリからすっかり間が空いてしまいましたが、暑さも和らいだことですし、また、Tetra21について述べてみたいと思います。

前々回のエントリ（ＭＤＩについて）で、Tetra21はMDIアプリケーションであると述べましたが、Single Document Interfaceも備えています。但し、Windowsでは、メインフレームウィンドウは一つという協約（守っていないアプリも時々見受けます）がありますので、SDIフレームウィンドウは先のメインフレームウィンドウをオーナーにしています（注意：子ウィンドウではありません）。こうすることで、前回のエントリ（帳票ＭＤＩのしくみ）の「フレームウィンドウ一つで全体を云々」が覆ることはありません。

このSDIフレームは「表一括編集」を受け持っています。クラス構成は三階層４クラスになっています。基本クラスから掛率拡張クラスを派生し、それから仮想合計付クラスと複数行編集クラスを派生しています。（次回エントリ予定の「ドック＆ビューアーキテクチャ」も参照してください）

では、何故MDIにしなかったのでしょうか？
一番の理由は、「行プロパティシート」に対して、前作のＤＡＣＥ－Ⅲの様な全体編集のUIを持ち込みたかったからです。当初はモーダルにする予定でしたが、行数が多いことからモードレスの方が有用であると判断し、唯一のフレームに制限しつつそのように実装しました。また、MDI同士は対等のイメージが有りますが、「表一括編集」はあくまでも一時的な編集のためのUIと言うイメージです。実は、前節の帳票ウィンドウも同じような立場にあったのですが、複数の帳票を平行して扱う必要性からMDI子ウィンドウにしておきました。（仕組みは違うが、表一括編集SDIは主目的が編集、帳票MDIは表示が主目的と言える）「表一括編集」ＳＤＩクラスは、種々のデータを統一したＵＩで操作する目的で導入しました。

現時点では、基礎データの「表一括編集」を基底クラスに、見積書用の「表一括編集」クラスを派生し、更に金額検討表用の「表一括編集」クラスと「見積書二行編集」クラスを派生しています。将来の方向としては、接続するドキュメントに合わせた派生クラスを利用することで、編集機能をよりマッチしたものに向上させるよう、計画しています。

皆さん、こんにちは。Dr.テトランです。

前回の「MDIについて」において、帳票ウィンドウは別扱いのような記述をしましたが、今回帳票ウィンドウについて少し詳しく述べてみたいと思います。

一般の表ブラウザウィンドウと同様に、帳票ウィンドウもTDBをブラウズ（＆修正）するためのUIですが、大きく異なる点があります。このMDIが最終資料を提示する目的で作られているためです。

■表示様式（書式）をユーザが指定できます
表ブラウザでは、表示項目の選択とその配置、レコードの選別とソーティングぐらいですが、帳票ウィンドウでは、予め導入されたオブジェクト（ページ、矩形、表）に限定されはしますが、 TDB上のデータを任意に関連付けることが可能です。（但し表は一種類のみ）とは言っても、目的の表を設計することは至難の業になりますので、Tetra21ではドキュメントの種類に応じて、 幾つかの表（ＩＤ）を予め用意し、ユーザはそれをカスタマイズすることになります。

例えば、ドキュメントが見積書シートならば、「工事総括表」や「見積明細書」「工事原価台帳」等々です。 後は、表示したい列項目をそのプロパティと共に定義し、必要に応じて矩形項目を配置すれば、概ね目標だった帳票が形式的にできると思います。 プロパティの中には、ページに依存するものや特殊な指示を書き込むための矩形もありますが、基本的にはページには依存せず、全頁同じことを繰り返します。但し、このことや表が一種類のみという制限が、特殊な帳票への対応を難しくしているのも事実です。

■加工して表示できます
表ブラウザが、TDBの指定した部分を、ほぼそのまま表示しているのに対して、帳票ウィンドウでは目的に応じた補正を施すことができます。 これは、行方向に顕著で、同じ種類のレコードを合計して纏めたり、不要なレコードを排除したり、逆にレコードを付け足したりします。 この加減を設定するのがスタイルシートです。

では、いよいよ「しくみ」について述べたいと思います。既に述べたことですが、表ブラウザの場合は、UI等を司る基底クラスからそれぞれのドキュメント固有の特性に対応するための派生クラスを作っています。 つまり、ドキュメントの種類だけクラスがあります。しかし、帳票ウィンドウでは一種類だけです。帳票ウィンドウクラスは、帳票（ビュー）の書式（パラメータ）とそれを設計するUIだけを持っています。 つまり表示するべき中身の性質には一切触れません。そういった意味では、表ブラウザの基底クラスと同様です。しかし、表ＩＤ毎に派生クラスを作るのではなく、データソースとなる表ブラウザとリンクして、その任に当らせます。

一番の理由は、単純に派生させようとすれば、追加するメソッドが膨大になってしまったためです。 多重継承と言う手もありますが、MFCがそのように仕組まれていないのと、動作時の仕組みとの整合性から、リンクしてそのドキュメントクラスから、描画時のセルデータを逐一もらうことにしました。

そのデータを準備させるために、帳票ウィンドウクラスはリンク確定（ソースドキュメントからの起動も含む）時と、「最新情報に更新」、「スタイルの変更」両コマンドを受けた時点で、表ＩＤや必要パラメータを伴って、ソースドキュメントの専用初期化メソッドを呼び出しています。 つまり、「スタイルの変更」は帳票ウィンドウのコマンドですが、UIを提供してそのスタイルのデータを準備しているのは、データソースとなる表ブラウザ側なのです。その結果、帳票ウィンドウ接続中にデータを修正しても、リアルタイムで帳票側が変わる場合とそうでない場合が起きます。それは、この初期化によって作られたデータか否（こちらがリアルタイム）かによります。

皆さん、こんにちは。Dr.テトランです。２０１３年が新たに始まり、すでに一か月が経過していますが、本年もよろしくお願いいたします。

さて、暫くサーバとサブシステムの話が続きましたが、ここいらでクライアントプログラムに移ります。 最近、新たにリリースされたプログラムでMDIを採用するものが少なくなったように思われますが、WordやExcelは相変わらずMDIを採用しています。（尤も、最近のものはかなり異なったビュースタイルになっているので、下記の文はTetra21のイメージです）Tetra21クライアントも採用している、このMDIについて少し述べてみたいと思います。此処からは、暫くTetra21デザインに直接かかわるような内容は余りでてきませんが、システムを理解する上で重要ですので是非読んでください。

正式にはMultiple Document Interfaceとして、Windows 3.0でAPIサポートするようになったUIで、見かけ上はメインのフレームウィンドウ内に複数のMDI子ウィンドウを設け、個々のドキュメントを結びつけることで、１プロセス内で複数のドキュメントを同時に操作できるUIです。フレームウィンドウを最大化してデスクトップに見立てると、複数のウィンドウズプロセスがあるように見えますが、その名が示す通り子ウィンドウなのでメニューバーはフレーム側についています。そして、子ウィンドウのアクティビティが変わるに連れてそのメニューバーも変わります。ちょっと昔のMAC風です。見かけ上は複数のプロセスでも、実際はシングルプロセスなのでMDI子ウィンドウ間でのデータ交換はストレス無く行えます。Tetra21クライアントがデータ交換やリンクの設定にD&Dを利用している背景にはこのような事情があるわけです。因みに、別プロセスのTetra21クライアント間では、D&Dは不可能です。従って編集目的ならば同じプロセス内で行うと便利です。この外にも、フレームウィンドウ一つで全体を一括して扱える利点が有ります。例えば、タスクチェンジや終了等、個々に行う必要は有りません。何故利用するアプリケーションが減りつつあるのか不思議です。

助言：データからTetra21クライアントを開く場合、同じプロセスで行うには、関連付けＵＩでDDEメッセージを [open("%1")] に設定してください。（私は、dc4とtpfをそうしています）

Tetra21クライアントでは、帳票ウィンドウを除いてMDI子ウィンドウでの操作性を統一するために、UIを含め基本的な機能を持つ基底クラスを作成し、各々のドキュメントはその派生クラスでまかなっています。 基本クラスには、左ペーンにツリービューを持つものとそうでないものが有ります。右側はリストビューに似た純正のビューがあり、こちらはダイナミックスプリッタ付で、全ての基本UIを提供しています。派生クラスでは、そのドキュメントに相応しい処理を追加及びオーバーライドしています。 こうすることでプログラムをコンパクトにすると共に、共通の操作性を提供しています。帳票ウィンドウも基底クラスと二つの派生クラスでできています。見積書表紙とそれ以外の一般帳票がそれです。但し、パラメータをより一般化することで、差異がなくなってしまったので、表紙クラスは、過去の帳票ファイル（*.hys）のためだけに残されています。この単一の帳票クラスで多様な帳票をまかなう仕組みのヒントは、２節「リソース消費量を決めるパラメータとパフォーマンス」の「⑥帳票パラメータについて」に有りますが、節を改めて解説します。

注釈：「見かけ上は云々」とあるのは、実際のウィンドウ構成とその連携はもっと複雑だからです。興味のある人は、先ずSDKを参照してください。

皆さん、こんにちは。Dr.テトランです。

さて、ここらでTetra21クライアントの根幹を成すDocument/View Architecture（ドキュメント/ビュー アーキテクチャ）について簡単に説明します。

ウィンドウズプログラムは、表示したいデータをスクリーンに書き込めば良いコンソールプログラムと違い、システムの要求に答えていつでもすばやくビューを再描画する必要が有ります。

そこで、ウィンドウオブジェクトを構成するのに、データを保持し必要な処理を施すドキュメントクラスとそれを表示するためのビュークラスに分けたものが、ドック＆ビューアーキテクチャです。

実は、ウィンドウズと複数形の表現で解るようにビューは複数ありえるわけですから、それを入れる（親になる）フレームウィンドウクラス（複数可）も必要です。

更に、ＭＤＩの場合はこのＭＤＩフレームが複数になるのが普通です。

前節まで、表ブラウザ基底クラスだの見積書クラスだの帳票クラスだのと簡略して言ってきましたが、正確にはそれぞれがドキュメント・ビュー・フレームの各クラス群で構成されています。

Tetra21クライアントのクラス継承図を付録として添付してありますので参考にしてください。

勿論、圧倒的多数を占めるそれ以外のクラス（その殆どがダイアログＵＩ）は除いています。

普通のアプリケーションでは、個々のドキュメントインスタンスは独立していますが、Tetra21ではサーバを通して間接的に、あるいは先の帳票ドキュメントの様に直接関与（リンク）しています。

直接関与しているものには、他に見積書と検討表、工種組換シートがあります。

こうした関連性から、Tetra21クライアントのMDIは相互作用を前提にした動作になっています。

先ほど「表示するためのビュークラス」と簡単に述べましたが、このビュークラスのコーディング１つでプログラムの応答性能（機能ではありません）が決まってしまいます。

別に、マウスやキーボードインターフェースが必要であること（こちらも大事な実装ですが）を指している訳ではありません。

実はウィンドウズシステムは、再描画が必要なウィンドウに対しては、描画域に合わせた描画マスクを用意した上で、外郭の矩形情報を伴って描画メッセージを送ります。

受け取ったビューは、描画に関与するドキュメントだけを処理対象として、マスク内で背景とデータの描画を行うようにします。

また、自身が再描画要因を作る場合もあります。

例えばサイズの変更や、データ変更をビューに反映させる時がそうです。

この場合、再描画領域が最小になる工夫と、「ちらつき」を防ぐために、背景を温存させるような配慮が大切です。（何れも関連メソッドのオーバーライドが必要）

Tetra21クライアントでは、場合によってはイレースバックグラウンドメッセージを無視して背景を書かずに、データと同時に書くことで、文字の「ちらつき」にも配慮しています。

このために、ディスプレイコンテキスト（画面）に直接書かずに、その部分と等価なメモリコンテキスト（メモリ）を作成し、そこに完全な描画を行った後に、一気にディスプレイコンテキスト（画面）にビットブリット（コピー）することもあります。

しかしながら、メニューバーやキャプション、ＭＦＣオブジェクトがそうなっていない（相変わらずイレースしてから書き込んでいる）のは残念です。

そう言う訳で、Tetra21ではビューやフレームウィンドウにＭＦＣが用意した登録済みクラスは使っておりません。

（ＭＦＣフレームワークは、はっきり言って初心者向けです）

皆さん、こんにちは。Dr.テトランです。今年もあとわずかですね。少し間が空いてしまいましたが、今回は4GB限界とサーバプログラムと題して述べてみたいと思います。

セグメントを固定したi386が提供できるアドレス空間は、32ビットオフセットだけなので、4GBが限度です。これを先に述べたようにOSと分け合うので、実際にアプリケーションが使用するのは2GB迄です。（3GB迄拡張できるツールもある） 一般のアプリケーションならばこれで十分な広さでしょうが、メモリーマップドファイルを使うDBMSにとっては、問題になってくる場合があります。Tetra21サーバでも、レコードパラメータに制約が出てきます。（これは、管理しているデータ全体のことではありません。全体の制限はメディアサイズやＰＣの能力で決まります。）

勿論、仮想メモリへのマップはスレッド共通で、しかも動的に行っており、仮想とはいえ無駄にメモリ空間を占拠しないような構成になっています。（通常は、スレッド単位に仮想アドレスを取得するので、益々2GB限界に当たり易い）しかし、それでもインデックスサイズの増大と共に32ビット限界が見えつつあります。この問題をプログラムで解決する方法は二つ考えられます。
 

一つは、インデックスを項目別に分けてレコード長を短くするか、インデックス全体をビューにマップせずに、特定のサイズに分けてマップしながら使う方法です

全て既知の方法で対処可能ですが、実空間の拡張が望めないので、パフォーマンスが犠牲になります。特に、「一部をビューにマップする」場合は、本来のマップオフセット（64ビット）を、i386のセグメントアーキテクチャのようにして、小分けして32ビットオフセットで操作することになり、管理が複雑になってしまいます。
Ｔｅｔｒａ２１サーバの場合、レコード数が大きくレコード長も長くなりそうなテーブルに、「物件概要」があります。リビジョン７７以降のサーバであれば、現在の最大レコード長を知らせる能力（DB情報UIを参照）があるので、その値を基に再構成すると良いでしょう。

もう一つは、DBMSの64ビット化です

既に2GB以上の実メモリが当たり前になった現状では、こちらの方が高いパフォーマンスを実現できます。但し、64ビットの開発環境とソースプログラムの手直し（RPCIF部及びデータ構造を32ビット型で残しつつ、スタブや内部ポインタ関連の64ビット化）を行う必要があり、かなりの工数が見込まれます。勿論複数のプロジェクトにするつもりは無いので、32ビット環境でビルトする場合はこれまでと同じ実行コードが得られなければなりません。（当分32ビット版も必要）

（このモデルケースとして、弊社で無償提供しているプレイヤーアプリ（WFP4Exp.exe）を、上記の基準を満足するように64ビット化してみました。結果的には、想定以上の工数と困難さが伴いそうです。）

また、動作環境もそれに見合ったものが必要です。（CPU処理速度＆物理メモリサイズ）残念ながら、どちらも現在のところ開発計画には至っていないので、DBパラメータの設定で問題を回避してください。実メモリが2GBあるとして、マスタファイルの４つのTDB合計サイズが1GB程度なら、実用的なパフォーマンスを持てると思います。（レコード長の無駄を切り詰めることが重要です）

皆さん、こんにちは。Dr.テトランです。

前回のプロセスとスレッド～前編を踏まえた上で、そろそろ現実のOSの話を始めたいと思います。

Version3.1xまでの古いWindowsと異なって、それ以降のOSは各実行モジュール単位に独立したプロセスを割り当てています。具体的なCPUを想定する必要がありますので、以降はインテルのi386以降とします。i386はセグメントアーキテクチャを駆使することで64TBの仮想空間を扱えますが、MSでは（１セグメントに固定の）フラットメモリモデルにして、4GBの仮想メモリをプロセスに割り付けます。

これは、OSをインテルアーキテクチャに特化することなく、他のCPUも考えた結果でもありますが、この4GBの制限はそろそろ問題になりつつあります。アプリケーション実行に割り付けれられた4GBの仮想空間は、OSとアプリケーションで二分して、使います。このときNT系と9x系ではOS側の使い方に決定的な違いがあります。NT系では、その部分にはWin32Subsystemが載るだけで、肝心のOS本体は保護された別プロセスで動作しています。そして、Win32サブシステムはLPCを使ってWindows NT Executiveを呼び出しています。

今、あるファイルを複数のプロセスで共有することを考えます。別の節でも述べたようにファイルにアクセスするには多くのニーモニックを使いますので、その間他のプロセスからのアクセスを全てカットしておく必要があります。

例えば、アクセスする度に、排他オープン/クローズを繰り返します。しかし、ファイルを変更する場合は、先ず読み取っておいてから、処理した結果を書き込むのが普通ですから、その間排他オープンされたままですので、無関係なレコードへのアクセスもブロックされてしまいます。また、関連するファイルが複数の場合はさらに面倒を引き起こしてしまいます。そうでなくても、排他オープンしたプロセスがトラブったり、ネットワークに問題が生じた場合に他のプロセスが影響を受けてしまい、データの安全性も危うくなってしまいます。

これが、１台のコンピュータで複数のプロセスであれば、ミューテックスのようなプロセス間同期オブジェクトを利用することで、もっとスマートな解決法がありますが、そもそも異なるコンピュ－タの場合は、そのような訳にはいきません。一番の解決策は、各々のプロセスを二つに分けて、ファイルを操作する部分を、そのファイルが在るコンピュータに持ってくることです。更に、それらのプロセスを一つのプロセスにまとめてDBMSにしてしまえば、プロセス間の同期も必要ありません。但し、元々別のプロセスであったものは、それぞれの片割れと通信する必要があるわけですから、個々に仮想CPUを割り振る必要があります。

それがスレッドです。部分プログラムの実行単位と思ってください（実はその下にファイバーがあります）。このようにすれば、同期オブジェクトもプロセス内であるため、オーバーヘッドを小さくすることができます。手荷物の授受も簡単です。勿論、二分したプロセス間の通信機能が必要で、Tetra21ではRPCを使っています。こちらの実現法は既に述べたとおりです。