「Windows」カテゴリーアーカイブ

Microsoft.Win32.OpenFileDialog for .NET 4.0

今日 IronPython を少し試していて気が付いたのだが

# -*- coding: UTF-8 -*-

import clr

clr.AddReferenceByPartialName("PresentationFramework")

import Microsoft

def dlg_open():
    dlg = Microsoft.Win32.OpenFileDialog()
    dlg.ShowDialog()

dlg_open()

あれ？Windows 7 標準のダイアログになった。
この関数だと XP 時代の古いダイアログになってしまうはずなのに。
x64 の Windows 7 だからなのか IronPython が .NET 4.0 版だからなのか？

IronPython – Release: 2.6.1

試しに .NET 2.0 版の IronPython zip 版も落として実験。
同じコードを動かしてみる。

やはり 2.0 版だと Windows 7 でも古いまんまだ。
なるほど、.NET 4.0 は同じ関数でも地味に改良してくれているんだね。
WPF を使うのが少し楽になった、地味に調べてみると面白いかもしれない。

SeeMe V5 001

SeeMe for Windows の Opera 10.60 対応版は IronPython で作ります。
一年前に途中まで作ってみたけど色々あってボツにした下記をベースで。

SeeMe is to IronPython

Linux しか使わなくなった作者が Windows のアプリを作るのは苦痛でしかない。
というより作者自身が使わないアプリを作ってもメンテナンスに疑問が残る。
こんな需要が少ないアプリを他の人がやってくれるとも思えない。
それより今の C# という言語が自分の趣味に合わない、Ruby が嫌いな理由と同じ。
ついでに VisualStudio を使いたくない、コンパイルもメンドクサイ。

一週間悩んだ結果、好き勝手にやることにした。
使いたい人は IronPython を導入してくれ、というトンデモネェ暴挙をマジでやる。

もちろんスクリプトのままで配る。
Windows しか使えない人の大半は EXE でないと拒否反応をするのは知っている。
それがキッカケで IronPython に興味を持ってくれる人が増えれば嬉しい。

戯言終わり、ということで。

xml:lang

現行の IronPyton では XAML に xml:lang=”ja-JP” を追記せずとも文字化けしない。
結局アレは IronPython のバグだったのだろうか？

WPF ListView DataBinding for IronPython

この pyevent.py をコピーさせなければいけないのもなんとかしたい。
ということでよく考えてみたらコレでいいのでは？と。

from System import *
from System.ComponentModel import *

# Search pyevent.py
import sys
tutorial_path = IO.Path.GetDirectoryName(sys.executable) + "\\Tutorial"
sys.path.insert(0, tutorial_path)
from pyevent import *

zip 版でも exe パス直下に Tutorial ディレクトリがあるのでイケるはず。
なんにせよ INotifyPropertyChanged は使わなければいけないわけで。
ただ zip 版を考えると os.path.join() は使えない…
追記 System.IO.Path.Combine() ってのがあった。

.NET Framework required BOM

この件もあった…
inifile8.py は他に os.path.exists を System.IO.File.Exists に書き換えて…
sys は組み込まれているけど他は Python 標準モジュールを使わないように…

SeeMe for Linux と共用できるコードがほとんど無いんだなコレが。

あとは x64 を見分けて Opera デフォルトインストール場所振り分けとか。
それから何があったかなぁ？もう少し更新が遅れるのはご了承。
とりあえず現在までのバックアップ。

seeme5_001.zip

少し楽しくなってきた、こんなことをやりながら作り上げていくのが楽しいんだよね。
「プログラミングを楽しむ」と「アプリを作って楽しむ」とでは実は少し違うのよ。

Visual Studio 2010

Visual Studio 2010 はこんな優待パッケージがあるのね。

今日現在 33,390 円にて予約受付中。
たしかにアップグレード版との比較なら超お買い得なんだが、正直微妙な値段設定だ。

Standard Edition ライセンス保持者対象だなんてありえない、挫折者九割越えが目に見えているのに。
VC6 の時一度挫折した人間は思う、Delphi 5 がこの世に出なかったら今の私は確実に只のオッサン。
開発に興味を持つ若い人の意識が当時と全然変わっていないなんて Blog 検索をすれば解る。
大げさに書くと統合開発環境を手に入れれば魔法のようにアプリが作れると思い込むとかね。

.NET Framework のメジャー更新毎に六万円を支払うことに疑問を持った人達を引き止めたいのかも。
それだったら一万円代が限界かと…

とはいえコッチより全然安い。
一旦 Std 版を手に入れ安上がりに Pro 版を仕入れたいなら面倒だけどこんなルートがある。
VS2008 Pro を持っている私には関係なかったりするんですけど。
少なくとも公開するアプリを作りたいなら正規のライセンスを持っていないと後が怖い。

さて私はどうしよう？
minipoli のメンテを続けるだけなら VS2008 のままでイケるわけで。
C# で SeeMe 以外を作りたくなったら、それまで待つと売り切れの可能性。
しかしその頃には別の販促バージョンが出るような、これは迷う。

IronPython つか DLR の初期化がもう少し早ければ笑い飛ばせるんだが…
と、Ubuntu Linux の Gedit で書いている現実では説得力の欠片もありゃしねぇ。

.NET 4.0 on IronPython

.NET Framework 4.0 の日本語版が出たようだ。

窓の杜 – 【NEWS】マイクロソフト、“.NET Framework”の最新版「.NET Framework 4」を公開

そういえば Windows 7 を立ち上げるのは一ヶ月ぶりくらいのような…
もう Windows に対しては .NET がどうなった？以外に興味が無いのかも…
せっかく買ったんだから使いたいんだけど Linux のほうが圧倒的に便利だし…

とにかく早速インストール。
二十分くらいで終わった、以外に早かった。

早速 4.0 を動かして…
ってアプリが無い。

そういえば IronPython 2.6.1 の .NET 4.0 版ってのがあった。
.NET 2.0 版を削除して入れ替えて使ってみよう。
普通にダウンロードすると 4.0 版が落ちてくるんだね。

IronPython.net /

4.0 版のデフォルトインストール位置は以下になる。

C:\Program Files (x86)\IronPython 2.6 for .NET 4.0

2.0 版から入れ替える人は環境変数の変更なんかを忘れずに。

それから、これは IronPython が悪いわけではないけど。
私は IronPython 関連の関連付けをこうしていた。

ぱぇぽぃ２ ? Blog Archive ? IronPython への関連付け

んでこんなのを作ってスタートアップ登録して利用していた。

ぱぇぽぃ２ ? Blog Archive ? NotifyIcon to use from IronPython

ファイルの右クリでプロパティから新しい ipyw64.exe に関連付け変更ができない！
2.0 時の情報がレジストリに残っていて存在しない exe 扱いになっちまったようだ。

HKEY_CLASSES_ROOT\pyw_auto_file
HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache

なんかの関連するものを丸ごと削除したけど EXE 情報が空になる。

HKEY_CLASSES_ROOT\Applications\ipyw64.exe\shell\open\command

を書き換えて、まあコレで関連付けはなんとかなったが…

なんだこりゃ、これはレジストリのドコを弄くれば修正できるのだ？
とにかく何でもかんでもキャッシュするのは迷惑なだけだ、特にアイコンキャッシュが。
Linux のほうがイイや、こういう細かいところで Windows を使う気が失せる。

ってコレは Windows への不満だし、気を取り直して実行。

さて ipy64.exe の初期化速度は、全然変わっておらずスゲェ遅い。
予想していたけど DLR はもう少しなんとかならないものか。
初期化さえ終われば実行速度も不満が無いし 2.0 版と同様に使えるのだけど。

上記の自作トレイアイコンもそのまんま動いた。

ぱぇぽぃ２ ? Blog Archive ? WPF Simple TextEditor example

も問題なく動く、3.5 までのコードはほとんど弄くらないまま 4.0 で動きそう。
新機能は知らないので後で調べる。

Default argument

Python という言語は関数のオーバーロードができない。
何って、つまり引数が違うだけで同じ関数名を利用する多重定義のことである。
慣れると関数やメソッド量を少しでも減らそうとよく利用するようになる。

だからといっていくつも別名の関数を用意するのは効率が悪い。
結果似たようなことができるデフォルト引数を利用するようになるわけだ。

ん、そういえば C++ や C# もデフォルト引数って使えたよな。
色々な言語を行ったり来たりしている私は同じように書いたほうがいいのでは？
それにデフォルト引数のほうがコードの記述量が減らせるメリットがある。
コンパイル後の機械語では似たような結果になるのだろうけど…

コードが短くできるのは魅力なので C++ や C# でもデフォルト引数をなるべくやろう。
オーバーロードはよく使うから覚えているけどデフォルト引数は C++ でどう書くの。
一つの cpp 内での書き方なら簡単に見つかる、Python とまったく同じか。

けど別ファイルにするには？
やってみた。

Tool.h

#pragma once
extern int messagebox(HWND hWnd, LPCWSTR msg, LONG button=MB_OK, LONG icon=MB_ICONEXCLAMATION);

Tool.cpp

#include "StdAfx.h"
#include "Tool.h"

#define MSG_TITLE L"確認 - Y901w"

int messagebox(HWND hWnd, LPCWSTR msg, LONG button, LONG icon)
{
	return MessageBox(hWnd, msg, MSG_TITLE, button | icon | MB_SYSTEMMODAL);
}

を用意してメインウインドウで使ってみる。

#include "Tool.h"
//略
messagebox(hWnd, L"ウニコード", MB_OKCANCEL);

extern 宣言で使う場合は extern 宣言のほうにだけデフォルトを書けばいいようだ。
本当は名前空間か class で static にするほうがイイと思うけどコレが一番簡単。
Python のように自作関数は小文字と掟を作っておけば間違えることも無いだろう。

しかし今になって昔のコードを見るとメンバ変数に m_ を付けていないとかで迷う。
自分が書いたコードなのに似たような変数名をローカル変数にしていたら迷ってしかたがない。
だから m_ プリフィクスみたいな書き方を推奨しているのね、そうなることが解っているから。
Python の self 強制って実はありがたいと思った、C++ も this 強制でいいくらいだ。