2020/06/07
から 松原正和
4件のコメント
これまで、自分は「ジオメトリ」というものをよく知らなかったのですが、お仕事の関係上これからジオメトリ関連をよく扱うことになるので、A5:SQL Mk-2 のジオメトリ対応させていきます。
とりあえず、PostgreSQL(PostGIS)のGeometry型対応です。…なんか最近はMySQLでもジオメトリ対応している？？？。
Version 2.15.0出したばかりですが、Version 2.15.1でGeometry型対応をちょっと入れます。
Geometry型はユーザー定義型として、バイナリデータ型として扱われます。このままデータを取得すると、OpenGISのWKB形式(HEX表現)になってしまうのですが、これをA5:SQL Mk-2側で解釈してOpenGIS のEWKT形式（ ST_AsText() 関数で得られる形式…多分）で表示するようにします。
本当は、地図も同時に出せるとよいのだけれど、それはもう少し後になると思います。
2020/06/07
から 松原正和
0件のコメント
A5:SQL Mk-2 Version 2.15.0 をマイクロソフトストアで配布し始めました。Vectorはもうちょっとかかるようです。
でさっそく不具合というか制限というか、どうしようもないのでわかってリリースしたのですが、A5:SQL Mk-2 Version 2.15.0のテーマ機能と高DPI環境はあんまり相性がよくありません。
テーマ機能は、見た目を変える機能で、Windows標準のコンポーネントをかっこよく（多分）見せる機能です。
一方、高DPI環境はこれまでのWindowsでは、96dpiを前提としていたフォントサイズをそれ以上(144dpiとか192dpiとか)とすることで4Kディスプレイなどで、文字や画像(用意した場合)をきれいに表示する機能です。（なお、A5:SQL Mk-2の高DPI対応では画像はこれまでのものを拡大表示しているだけです。）
で、高DPI環境で、テーマ機能を使った場合なのですが、どうも、ウィンドウのタイトルバーの高さが高くなりすぎてしまう関係上、ダイアログボックス等で、高さが足りなくなって一部ボタンが見切れてしまうようになってしまいました。
上の例ではかろうじてOKボタンが見えているものの、ダイアログによってはボタンの判別がつかない場合もあるようです。これは、利用しているライブラリの仕様上、修正が難しいと考えています。Version 2.15系では、高DPI環境下ではテーマ機能は使わないほうがいいかもしれません。
2019/12/22
から 松原正和
0件のコメント
A5:SQL Mk-2で絵文字を使うと、こんな風に表示されます。
世の中にはカラー絵文字というのがあるそうで、WindowsではDirectDraw(DirectWrite)を使うとカラー絵文字が使えるらしい。何となくやってみたいなあと思い、テキストエディタコンポーネントをちょっと修正してみました。
カラー絵文字は表示されたものの、行番号が表示されないし、文字がちょっと見切れている。スクロールすると文字が消える…。文字描画だけをDirectWriteに変えただけではだめそうだ。どうやら、GDIとDirectDrawを共存というのは難しいらしい。グラフィック全ての描画をDirectDrawに切り替えないといけないようだ。
テキストエディタコンポーネントの描画をすべて修正するのは難しいし、この修正は当面リリースできなさそう?。
2019/10/27
から 松原正和
0件のコメント
A5:SQL Mk-2のERエディタでは、これまでリレーションシップの線は最大でも「横線-縦線-横線」又は 「縦線-横線-縦線」 など、３本の線までしか対応できていませんでした。これまでも、もっと自由に線を引きたいとのご要望は受けていたのですが、なかなか大変で実装できていませんでしたが、Version 2.15.0 beta 23でようやく対応してみました。
このモードはリレーションシップの線を選択して右クリックして、線種から「自由結線」を選択することで利用することができます。
最初は直線で表示されますが、直線の中間地点にあるグレーのハンドルをドラッグすることで頂点を追加できます。
頂点を削除するには、頂点の赤いハンドルを選択して右クリックメニューから「頂点の削除」を実行すると削除できます。
なお、サブモデルの機能を使えば、あまり複雑な線を引かなくとも（自由結線モードを使わなくとも）それなりにER図を描くことができます。あまり複雑な線を描くと、かえって分かりづらくなったりすると思います。https://a5m2.mmatsubara.com/tips/er_submodel/
2019/09/29
から 松原正和
0件のコメント
90年代とか昭和とか言われるA5:SQL Mk-2のデザインセンスですが、テーマ機能を使うととりあえず、ぱっと見の見た目をマシにすることはできます。
ただ、このテーマ機能はやや重い機能であるとか、高DPIで使うとタイトルバーが細くなってしまうとかいろいろ問題があるため個人的にはあんまり好きではありません。
テーマ機能を実装するより前から、テーマ機能とはべつに「テーマカラー」機能を実装していました。テーマ機能がデフォルトの「Windows」であるとき、この「テーマカラー」機能が使えます。テーマカラーはA5:SQL Mk-2の背景色（通常は灰色の部分）を決定する機能です。これを変えるだけでもモダンとまではいかなくとも、そこそこ印象は変わるかもしれません。
今回、Version 2.15.0 beta 19から、このテーマカラーのデフォルト色を灰色（システムのボタン表面色）から「薄灰桜」というやや淡いピンク基調の色に変えてみました。（A5:SQL Mk-2のテーマカラーの色は日本古来の色の名前を使っています。）
今までのデフォルトのテーマカラー
新しいデフォルトのテーマカラー（薄灰桜）
どうでしょう？
なお、使用中の環境を更新していてテーマカラーが変わらないばあい、オプションダイアログの「全般」タブから選択することができます。
2019/09/23
から 松原正和
0件のコメント
偏差値 46の現状を打破すべく、Delphi用ライブラリであるDMonkey(ECMAScriptエンジンのサブセットライブラリ)のUnicode対応版をGitHubにアップしてみました。
https://github.com/m-matsubara/DMonkey
ECMAScriptといっても、やや古いECMAScriptの仕様なので、現状どの程度の需要があるのかはよくわからないですが。
このライブラリは以前、A5:SQL Mk-2をUnicode対応したときに一緒にUnicode対応したものです。
元々、Version 0.3.9 をベースにUnicode化してA5:SQL Mk-2に組み込んでいましたが、GitHubで公開するのに合わせて、最新のバージョンである、Version 0.3.9.1に追従しています。（何か不具合仕込んでしまっていなければいいのですが…）
また、README.mdにも記載していますが、Unicode化に伴って廃止・追加されたオブジェクトやメソッドがあります。
2019/09/16
から 松原正和
0件のコメント
これまでA5:SQL Mk-2のソース管理は自前で建てたgitサーバーを利用していました。GitHubがプライベートリポジトリを無償で使えるようになったというのでどうしようかな～と思っていたのですが、思い切って載せ替えてみることにしました。
gitリポジトリの移行は以下のコマンド(Qiitaより引用)
|
1 2 3 |
$ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd <REPOSITORY> $ git push --mirror <DESTINATION_REPOSITORY_URL> |
何かトラブルがあるかと思ったのですが、あっけなく完了しました。
あんまり今まで知らなかったのですが、GitHubにはContribution Graph（通称芝生）というのがあり、コミット数に応じて、日ごとのマス目がどんどん緑色に染まります。自分のは以下のような感じ。
すごい人はほんとに芝生のように青々としているみたいですが、自分のはそこまでいかないですね。これだけ見るとまるでサンデープログラマです。むしろ、会社休んだ日がバレてしまうのではないかといった感じ。まあ、平日は家事・育児が忙しいので。（子供たちが小学校に入ったら途端に忙しくなった。）
ただ、これまではgitサーバーは補助的に使っているだけで、ソース管理は、ビルドするごとにソース全体をzipで固める運用（そしてOneDriveにバックアップ）をしていました。なので、gitサーバーにコミットしなくても全然問題なしで、実際gitサーバーにpushするのが面倒で全然pushしていない期間もありました。
実のところ開発に使っているフォルダとリリースに使うフォルダも分かれていませんでした。これからはこれも改めて、開発フォルダとリリース用のビルドフォルダを分けて、GitHubにpushされたソースをリリース用のフォルダからpullしてビルドするように、zipで固める代わりにビルドバッチ内でタグを打つようにします（しました）。これでGitHubへのpushもまじめに行うようになるはずです。（行わなければなりません。）
…ところで、FindyというサイトがGitHubの開発状況を見て「スキル偏差値」なるものを出してくれるのですが…自分の偏差値が「４６」…マジですか？、標準以下ですか？。頑張っているつもりなのだけれど…。
プライベートリポジトリだとダメなのかなあ？。こちらのサイトではプライベートリポジトリも審査の対象となるようなことが書いてあるのだけど、あまりプライベートリポジトリは重視されないんですかね？。
2019/09/15
から 松原正和
0件のコメント
この記事は、Delphiの最新バージョンである、Delphi 10.3ではなく、Delphi 10.2について書かれています。新しいバージョンでは状況が異なる可能性もあります。
最近4Kディスプレイを買ったのですが、これまでも4Kディスプレイ買おうかなと考えたことはありました。しかし 「Delphiの開発環境(IDE)の表示、どうなっちゃうんだろう？」 との不安があり、躊躇していました。
問題はDelphiはフォームの設計段階では、ウィンドウやコンポーネントの位置・サイズ指定をピクセル単位で行うことです。このため4Kディスプレイなどでは、「フォームデザイン」の画面が小さくなりすぎて支障をきたさない？などと考えていたわけです。うまくフォームデザインの画面を拡大表示してくれるのでしょうか？。でも、Delphiで使うコンポーネントはデザイン画面でも実際に動作するのがウリのはずです。また、拡大縮小しなければならないプロパティはLeft, Top, Width, Heightだけとは限りません。それとも、TFormクラスにある、PixelPerInchプロパティが何か関係しているでしょうか？。設計時と異なるDPI環境ではこの PixelPerInch プロパティとの比率に従い画面サイズを調整してくれるのでしょうか？。複雑なDPI変換のルールで、動作に支障をきたさないでしょうか？。
…４Kディスプレイを購入し、実際試してみたところ…そもそもDelphiのIDEは、そもそも高DPI環境に対応していませんでした。192DPI(200%のスケーリング)にしたところ、がっつり200％にスケーリングされます。全然フォントとかきれいになりません。
テキストエディタもカクカクフォントです。
ちょっと残念ですが、あえて高DPIに対応しないおかげでDelphiの開発環境は96DPI前提のまま ピクセル単位で 開発（設計）できるのですね。 上述したような画面設計をピクセル単位で行うことに由来する問題・懸念は発生しません。
ちなみに、、、高DPIに対応しないアプリケーションを無理やり高DPIに対応させて実行する方法があります。
「ダイジョウブ・ダイジョウブ」「イケル・イケル」と唱えながら、以下の設定を変えます。(Windows 10 1903の場合)
該当の実行ファイル(DelphiのIDEはbds.exe)のプロパティを開き、「高DPI設定の変更」ボタンを押します。
「高いDPIスケールの動作を上書きします。」にチェックを入れて、下のプルダウンから「アプリケーション」または、「システム（拡張）」を選択してOKを押します。
「アプリケーション」の設定では以下のようになりました。
フォントはきれいですが、開発中の画面は指定値通りに小さくなります。ただし、タイトルバーやメニュー・非ビジュアルコンポーネントのフォントは大きくなります。あまりこのまま開発してよさそうな気がしません。
「システム（拡張）」の設定では以下のようになりました。
何か微妙にところどころフォントがきれいになるのですが、基本的にカクカクフォントです。あと、デバッグ実行されたアプリケーションまで「システム（拡張）」の設定が引きずられて96DPIで実行されてしまうようです。
DelphiのIDEはやっぱり高DPIに対応させないほうがよさそうですね。
そもそも、Delphiが画面の位置やサイズ指定をピクセル単位で行ってしまっているためだと思うのですが、DelphiのIDEは高DPI化の難しいアプリケーションのようです。最新のDelphi10.3は試していませんが、仕組み上難しいのかなあとも思います。Delphiで開発するアプリケーションは高DPI対応は問題ないのですがね。
2019/09/08
から 松原正和
1件のコメント
A5:SQL Mk-2は一応高DPI対応ということになっていますが、これまで私の開発環境は高DPIに耐えうるディスプレイではありませんでした。1680×1050という少し変則的な解像度のディスプレイ（フルHDですらない）を２枚使って、高解像度のテストのときだけ無理やり、スケーリングを150%とかにしてみたり…。
ということで、今回４Kディスプレイを２枚導入してみました。なかなかこれ自体大変だったのですが、今回の書くのは高DPI対応アプリケーションのお話。
Windowsにおける高DPI対応は以下の３つのレベルがあります。
Not DPI Aware は内部的には古いWindowsの標準DPIである96DPIで内部的に描画され、スケーリング（拡大）されて実際のモニターに表示されます。このため高解像度のモニターでは文字や画像がモヤっとして表示されます。高DPIに何も対応しないアプリケーションはこれになります。
System DPI Aware は起動時にDPI値が決定（多分メインモニターのDPI値）され文字はきれいに表示されます。画像ももやっとしません（個別に画像を用意する必要があります）。DPIの異なるモニターに切り替わるときはシステムが自動的にスケーリング表示に切り替える仕組みとなります。ただし、Windows 10（の最近のバージョン）ではスケーリング表示時でも文字だけはきれいに描画されます。アプリケーションでは、起動時にレイアウトの調整をしたり、解像度にあわせた複数の画像を用意する必要があります。
Per monitor DPI Awareは Windows 8.1から導入され、一番新しい対応レベルです。モニターを移動するごとにDPIの変更がアプリケーションに伝達され、アプリケーション内でDPI切り替えの処理が実行されます。アプリケーションでは、起動時とDPI切り替えである、WM_DPICHANGEDイベントでレイアウト調整や画像の切り替え処理をする必要があります。
A5:SQL Mk-2 Version 2.14系ではPer monitor DPI Awareに対応していました。開発環境である Delphi 10.2 も Per monitor DPI Aware に対応することになっています。ただ、実際DPI値の異なるモニター間の切り替え動作は正しく動作していなかったようです。A5:SQL Mk-2が今どき珍しいMDIアプリケーションであることも影響しているかもしれません。
色々試してみたのですが、なかなか完全対応は難しいようです。また、DPI切り替えの処理は複数ドキュメントを開いていると結構時間のかかる処理のようで、切替処理にモタついてしまうのもなんだかいけません。
これらのことから A5:SQL Mk-2では一つレベルを落とし、 System DPI Awareに変更することにしました。これなら、DPIの異なるモニター間を移動しても画面崩れなどは起きませんし、切り替え時にアプリケーションがモタつくこともありません。実際やってみて、表示もなかなかきれいに表示されているように思います。
実際のやり方は 以下の通り。
これまでは、Delphiのプロジェクトオプションで「アプリケーション」の「高 DPI の有効化」にチェックを入れていましたが、
System DPI Awareにするには、マニフェストファイルを自分で用意するようにします。
実際のマニフェストファイルの記述は以下の通り…。「<dpiAware>true</dpiAware>」というのが、 System DPI Aware に対応する記述です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" > <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> <asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>true</dpiAware> </asmv3:windowsSettings> </asmv3:application> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <!-- Windows Vista --> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> <!-- Windows 7 --> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> <!-- Windows 8 --> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> <!-- Windows 8.1 --> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> <!-- Windows 10 --> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> </application> </compatibility> </assembly> |
2019/08/28
から 松原正和
0件のコメント
A5:SQL Mk-2 Version 2.14.3 が公開されました。…が早速ちょっと不具合を発見。
Version 2.14.3 で構文入力支援の高速化をしたのですが、ちょっとミスしたようです。
普通に、Ctrl+Spaceで構文入力支援を呼び出したあと…、
何文字か文字を入力して絞り込むと、本来は構文入力支援の候補数がそれに合わせて減っていくはずですが、候補数が減らずに、空白が表示されます。
空白の行を選択しようとすると、選択行を表す、青色の反転も表示されなくなり…、
さらにその行を選択しようと、Enterを押下すると「引数が範囲外です」エラーになってしまいます。
大きな不具合ではないと思いますが、早めに修正版をリリースしたいと思います。