トップページ⇒tech
1001コメント291KB

ふらっとC#,C♯,C＃（初心者用） Part21

■ このスレッドは過去ログ倉庫に格納されています
0001ななしぃ#2007/11/18(日) 15:53:41
このスレッドは
「どんなにくだらないC#プログラミングに関する発言でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問など、
勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。

前スレ: ふらっとC♯, C＃（初心者用） Part20
http://pc11.2ch.net/test/read.cgi/tech/1191036844/
0524デフォルトの名無しさん2007/12/09(日) 00:41:46
＠と￥がいらなそう
0525デフォルトの名無しさん2007/12/09(日) 00:42:40
.txt\"";
0526デフォルトの名無しさん2007/12/09(日) 00:44:14
>>523
もうくるな
0527デフォルトの名無しさん2007/12/09(日) 01:35:23
すいません質問があります。

あるクラスAを継承したクラスBがあるとして、
クラスBのインスタンスからはAのpublicメンバを使用できないようにすることは出来るでしょうか？
例えばFormクラスを継承したMyFormクラスを作ったが、Myformインスタンスでは勝手にクライアントサイズなどを変えてほしくない、などです。
0528デフォルトの名無しさん2007/12/09(日) 01:49:12
できません
0529デフォルトの名無しさん2007/12/09(日) 01:50:31
>>528
出来そうと思いましたが、そうでしたか。ありがとうございました。
05304802007/12/09(日) 02:56:59
>>484 >>485 レス有難うございます。
IntPtrってなんぞ、、、ってところから始まって、DllImportを初めて使ってみるまでに一日かかりました。ウヒー。
とりあえず日付は更新できるようになったものの、本当にこの書き方でよいのか激しく不安です。
添削していただけると有難いです。
[DllImport("coredll.dll")]
private static extern IntPtr CreateFile(String lpFileName, UInt32 dwDesiredAccess, UInt32 dwShareMode, IntPtr lpSecurityAttributes,
UInt32 dwCreationDisposition, UInt32 dwFlagsAndAttributes, IntPtr hTemplateFile);

[DllImport("coredll.dll")]
private static extern bool CloseHandle(IntPtr hObject);

[DllImport("coredll.dll")]
private static extern bool GetFileTime(IntPtr handle, ref FILETIME lpCreationTime, ref FILETIME lpLastAccessTime, ref FILETIME lpLastWriteTime);

[DllImport("coredll.dll")]
unsafe private static extern bool SetFileTime(IntPtr handle, FILETIME *lpCreationTime, FILETIME *lpLastAccessTime, FILETIME *lpLastWriteTime);

public struct FILETIME{
public UInt32 dwLowDateTime;
public UInt32 dwHighDateTime;
}
public struct FileTimes{
public FILETIME CreationTime;
public FILETIME LastAccessTime;
public FILETIME LastWriteTime;
}
unsafe static public bool SetFileTimeStamps(string path, FileTimes fileTimes){
IntPtr handle = CreateFile(path, 0x80000000, 0x00000001, IntPtr.Zero, 3, 0x00000080, IntPtr.Zero);
bool re = SetFileTime(handle, &fileTimes.CreationTime, &fileTimes.LastAccessTime, &fileTimes.LastWriteTime);
CloseHandle(handle);
return re;
}
0531デフォルトの名無しさん2007/12/09(日) 03:08:18
>>529
フォームの中の使うメンバだけを公開したクラスを作ってフォームにかぶせる
0532デフォルトの名無しさん2007/12/09(日) 03:21:43
>>527
newで書き換えちゃえば呼んでも変更されないってのは出来るけど・・・お勧めはしない

public partial class Form1 : ExForm {
public Form1() {
InitializeComponent();
this.Size = new Size(500, 500);
}
}
public class ExForm : Form {
public new Size Size {
set { }
get { return base.Size; }
}
}
0533デフォルトの名無しさん2007/12/09(日) 04:09:33
例外投げればいんじゃね。
05344852007/12/09(日) 05:07:01
>>530
API周りはMSDNと見比べたけど型の設定とかは間違ってないね。
ちょっと思ったのは、FILETIMEとFileTimesの実装かな。
両方publicで外出ししてるけど、クラス内に隠蔽して、メソッドの引数は
DateTime型で貰って内部で変換した方が呼び出し元から使うのは楽な
んではないかなと。
まぁ呼び出し側で日時をどういう形式で扱ってるかによるから好きな方
法で良いとは思うけど。
05354802007/12/09(日) 05:46:26
>>534
なるほど、確かにFILETIMEは毎回ビットシフトしてlong型に直す処理を外でしていたので
DateTime型で受けて内部で処理させた方がスッキリしますね。
有難うございます。

DllImportを覚えると、一気に出来ることが増えて、まさに世界が広がった感じがします。
楽しくなってきました（´∀｀）
0536デフォルトの名無しさん2007/12/09(日) 11:04:24
Wsdl.exeで登録したXMLWebサービスを削除するにはどうしたら良いの？
0537デフォルトの名無しさん2007/12/09(日) 13:11:05

Regexクラスで質問です。
あるファイルに変換前と変換後のデータが格納してあり、
文字列をその内容に従って変換したいのですが、\r\nの扱いがうまくいきません。

Regex rex = new Regex(strBefore);
strData = rex.Replace(strData, strAfter );

aaabbb → aaa\r\nbbb
(strBefore) (strAfter)

としたい場合、CRLFではなく、文字列として"\r\n"に変換されてしまいます。
エスケープシーケンスのオプションみたいなのがあるのでしょうか？
0538デフォルトの名無しさん2007/12/09(日) 13:12:49
ファイルから読み込むときに@"\r\n"を"\r\n"に変換しろ
0539デフォルトの名無しさん2007/12/09(日) 13:21:42
>>538
ありがとうございます。
うまく行きました。
0540デフォルトの名無しさん2007/12/09(日) 17:20:30
ツールチップの描画に使用されるフォント(デスクトップのプロパティのデザイン→詳細設定→ヒントで設定される奴です)を取得したいのですが、何か方法はないでしょうか。
0541デフォルトの名無しさん2007/12/09(日) 19:25:14
>>540
http://msdn2.microsoft.com/ja-jp/library/system.windows.forms.drawtooltipeventargs.font(VS.80).aspx
これ？
0542デフォルトの名無しさん2007/12/09(日) 21:10:15
抽象クラスで、フィールドとコンストラクタを継承することはできないんでしょうか？
0543デフォルトの名無しさん2007/12/09(日) 21:29:50
意味が分からない
無理に抽象的に書かなくていいから具体的にどうしたいのか書いて
0544デフォルトの名無しさん2007/12/09(日) 21:57:25
abstract class A
{
　　　　(略)
}


class B : A
{
　　　　(略)　　
}

class C : A
{
　　　　(略)
}


↑でクラスBとクラスCで同じようなフィールドを使って、さらにそれを同じ値で初期化するとき
クラスAのフィールドとコンストラクタが継承できたら楽だと思うんですが、できないんでしょうか？
0545デフォルトの名無しさん2007/12/09(日) 22:04:17
ベースクラスのフィールドにアクセスしたり、ベースクラスのコンストラクタを明示的に呼びたいってことか？
それならできる
0546デフォルトの名無しさん2007/12/09(日) 22:05:05
あるプログラムA（EXE、すでに起動して無限ループで待機中）でメソッドを提供し、
別のプログラムB（ASP）でこれを呼び出したいのですが、何かうまい仕組みが提供されてたりしますか？
プロセス間通信を自前で実装するくらいしか思いつかないのですが…。
0547デフォルトの名無しさん2007/12/09(日) 22:05:56
それ具象やん
0548デフォルトの名無しさん2007/12/09(日) 22:09:27
フィールドのアクセス修飾子をprivateではなくprotectedにすれば、派生クラスからもアクセスできるようになる。
ベースクラスのコンストラクタを呼びたければ派生クラスのコンストラクタを

public B() : base()
{
}

のように書けばいい
0549デフォルトの名無しさん2007/12/09(日) 22:10:01
>>545
すいません、同じ違いでした。

型名やフィールド名が"同じという意味です。

B.x
B.y

C.x
C.y

これらを一つ一つ宣言するより、親クラスから継承して
例えば全てに0等を入れて初期化する場合、コンストラクタも一緒に継承できると便利だと思うんですが……
0550デフォルトの名無しさん2007/12/09(日) 22:13:17
>>549
出来るから手動かしてみな
0551デフォルトの名無しさん2007/12/09(日) 22:19:28
>>546
リモーティング
0552デフォルトの名無しさん2007/12/09(日) 22:25:24
>>549
A.xとB.xは同じフィールドじゃなくて、たまたま名前が同じだけってこと?
protected void init(ref int x, ref int y);
みたいなの定義しといて、各コンストラクタから呼び出すとか
05535522007/12/09(日) 22:26:08
定義しといて→Aに定義しといて
0554デフォルトの名無しさん2007/12/09(日) 22:43:41
多分>>544は>>552みたいに複雑なことをやろうとしてるんじゃなくて、
継承とインスタンスがどのように挙動するかわかってないだけだと思うのだが･･･
0555デフォルトの名無しさん2007/12/09(日) 22:44:17
protectedの意味が分かれば終了だろ
0556デフォルトの名無しさん2007/12/09(日) 22:57:20
と、いうわけでアクセス修飾子の話でも。

public　何処からでもアクセス可能(アクセスレベルが低いと表現)
↑
protected　派生クラスはアクセス可能
↓
private　自分しか無理。(アクセスレベルが高い)

クラスAにposX、posY、graphic、というフィールドがあれば、
クラスAを継承したクラスBも、そのフィールドを持つ。
それらのフィールドのアクセスレベルをprotectedにしておけば、派生クラスでもフィールドに自由に代入・取り出しできる。
もしprivateだと、それぞれフィールドは存在するのに一切派生クラスからはアクセスできない、ということになる。
この場合はプロパティを基本クラスで作っておけばすれば解決できる。(というかgetとsetのアクセスレベルを分けるから大抵はこっち？かな)




0557デフォルトの名無しさん2007/12/09(日) 23:00:22
フィールドをprotectedにしちゃうのはお勧めできない
初期化はたいてい基底クラスのコンストラクタを呼べば済む
0558デフォルトの名無しさん2007/12/10(月) 00:07:18
継承なんてすんなよ。
0559デフォルトの名無しさん2007/12/10(月) 04:22:03
てか、フィールドをprotectedにするのは禁止じゃなかったか。
プロパティなら良い。
0560デフォルトの名無しさん2007/12/10(月) 10:27:11
誰が？
0561デフォルトの名無しさん2007/12/10(月) 10:29:23
オレオレ
0562デフォルトの名無しさん2007/12/10(月) 11:25:16
とある機器からUDPでHTTP1.1なデータを送ってくるのですが
受信と解析するようなクラスはありますか？
0563↑2007/12/10(月) 11:28:01
受信だけはUdpClientでできるんですけど
0564デフォルトの名無しさん2007/12/10(月) 11:33:59
WebClient
0565デフォルトの名無しさん2007/12/10(月) 12:09:29
>>561
ttp://nasu.x0.com/blog/program/index_2.html
0566デフォルトの名無しさん2007/12/10(月) 15:03:48
例外が起こる前にifで避けるのと、起こってからtry-catchで対応するのとどっちがいいですか？
こういう時はtry-catchを使うという判断基準ってあるのでしょうか？
0567デフォルトの名無しさん2007/12/10(月) 15:09:44
モノによるけど私はifで避けれることはifで避けるようにしてる。
try-catchでしか回避できない仕様なら仕方なしに使う感じ
0568デフォルトの名無しさん2007/12/10(月) 15:29:29
例外をキャッチするとわけわかんなくなるから
ifで出来るものはifでやった方がいいよな
ArgumentExceptionとか例外が投げられること自体がバグの証明であるようなのは
どんどん投げるべき
そしてキャッチさせないべき
そのためにtryで囲ませないべき
tryで囲ませると往々にしてバグまで握りつぶしてしまう
05695662007/12/10(月) 15:57:42
事前に避けられそうな奴は避けるべきなんですね。
早速コード直してみます。
ありがとうございました。
0570デフォルトの名無しさん2007/12/10(月) 16:12:28
教えてください。
WebBrowserコントロールで、
Internet Explorer の [ファイル] メニューの [名前を付けて保存] メニュー オプションのような
機能を実装しようとしているのですが、
以下のようなコードですとエラーがでます。
どうすればいいんでしょう。。。

AxWebBrowser3.ExecWB( ShDocVw.OLECMDID_SAVEAS, ShDocVw.OLECMDEXECOPT.OLECMDEXECOPT_DODEFAULT);ですと
'ShDocVw' は現在のコンテキスト内に存在しません。
とエラーがでてしまったのですが。。。

0571デフォルトの名無しさん2007/12/10(月) 17:31:41
using ShDocVw;
0572デフォルトの名無しさん2007/12/10(月) 17:32:55
OLECMDID.OLECMDID_SAVEAS
0573デフォルトの名無しさん2007/12/10(月) 18:29:19
using ShDocVw;を追加したのですが以下のエラーが出ました。
型または名前空間名 'ShDocVw' が見つかりませんでした。
using ディレクティブまたはアセンブリ参照が不足しています。
0574デフォルトの名無しさん2007/12/10(月) 19:20:05
コントロールを削除してもソースにイベントハンドラが残るんですけど手動で削除するしかないんですか？
0575デフォルトの名無しさん2007/12/10(月) 19:44:30
勝手に消えても困るだろ？
0576デフォルトの名無しさん2007/12/10(月) 20:05:55
ほかから参照されていないとかの条件なら消すかどうかの選択肢はあってもいいかもね
0577デフォルトの名無しさん2007/12/10(月) 20:46:51
>>573
shdocvw.dll参照にいれたんじゃなくてWebBrowserコントロールか。

ShowSaveAsDialog ってメソッドがあるでしょ。
0578デフォルトの名無しさん2007/12/10(月) 21:18:12
ShowSaveAsDialog();は、AxWebBrowserにはないみたいです。
shdocvw.dllは、参照にいれる必要ないんですか？
0579デフォルトの名無しさん2007/12/10(月) 21:37:12
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=42629&forum=7
0580デフォルトの名無しさん2007/12/10(月) 21:42:19
どっちかの質問取り下げろやハゲ
0581デフォルトの名無しさん2007/12/10(月) 22:41:02
WebBrowserコントロールと書いておきながらaxWebBrowserなのか？
0582デフォルトの名無しさん2007/12/10(月) 23:05:26
>>566
おれはめちゃくちゃcatchしまくってるよ。
おかげでエラーチェックのifが少なくなって、ロジックが超すっきり。
0583デフォルトの名無しさん2007/12/10(月) 23:09:29
ifやめてcatchにする方が
どう繋がってるのか分かりにくい
0584デフォルトの名無しさん2007/12/10(月) 23:12:50
catchの方がコスト高いでしょ？
0585デフォルトの名無しさん2007/12/10(月) 23:19:28
たとえば、CSVを読み込んで、DBに入れるコードを書くとして、
TryPerse() でなくて、Prese()で、intに変換。
FormatExceptionが飛んだら、このCSVは不正ですって言って、処理終了。

これでなんにも問題ありません。
0586デフォルトの名無しさん2007/12/10(月) 23:21:09
まあ終了する時は例外ほど便利なものはない
0587デフォルトの名無しさん2007/12/10(月) 23:53:12
趣味グラマか
0588デフォルトの名無しさん2007/12/10(月) 23:56:38
エラーコードはまだいいけど
null返してきたりスルーしやがるメソッドはうざい
0589デフォルトの名無しさん2007/12/11(火) 00:04:21
nullを返すのとbool TryHoge(out result)と例外返すのとどれがいい
0590デフォルトの名無しさん2007/12/11(火) 00:13:41
s@;w@mee;@s4ezdwh;
0591デフォルトの名無しさん2007/12/11(火) 00:42:53
例外
0592デフォルトの名無しさん2007/12/11(火) 00:43:34
TryParseよりParseがいいってか
0593デフォルトの名無しさん2007/12/11(火) 00:47:03
メソッドが不可避な例外を投げる場合、キャッチしなければバグになるわけだ
そしてそれがバグであるかどうかはドキュメントをよく読まないと分からない
TryHogeならばifで囲まれていない時点でバグであることが見た瞬間に分かる
どっちがいいかは分かりきっている
0594デフォルトの名無しさん2007/12/11(火) 01:22:57
というか、これは自分の想像だから間違ってたらただして欲しいんだけど、
昔のCの、intでエラーコードを返すタイプの関数から、
今の、voidでエラーが起きたときは例外を投げるタイプのメソッドに推移というか、
後者が主になったのは、なんらかの理由があるからじゃないの？
TryParseとかはその流れに逆行してるように感じたんだけど…
0595デフォルトの名無しさん2007/12/11(火) 01:25:42
そりゃ、TryParseのほうがタイプ量少なくて済むからな。軽いし。
ただし、boolを返すTryXxxを作るときは、例外を投げるXxxも用意することになってる。
0596デフォルトの名無しさん2007/12/11(火) 01:34:04
例外には2種類あって、ArgumentExceptionのように投げられること自体が呼び出し側の
ミスによるものであり、除去すべきバグであることが明らかなものと、
ネットワークのサーバがダウンしている、ファイルが存在しないといった
正しい呼び出し方をしたとしても起こりうるエラーがある
大半は前者だ。バグだから直さなきゃいけないというのを通知するのには例外は適している
失敗の可能性が不可避なメソッドならば、例外を用いずによりわかりやすいTry〜のような
形を用いるべきだ
Tryの形式なら一目でバグと分かるのに、わざわざ例外を使って
バグと分かりにくいコードを書かせる必要なんか皆無だ
どちらにもいえることだが、例外はキャッチするものでは無い
0597デフォルトの名無しさん2007/12/11(火) 01:50:28
要するにポリシーとしては、使い方に因らないエラーが発生する場合は例外を投げ、
使い方に因ってエラーが発生する場合は戻り値で返せということですかね？
0598デフォルトの名無しさん2007/12/11(火) 01:58:51
正しい呼び出しをしてない場合は例外を投げ
正しい呼び出しをしてもエラーが不可避である場合はboolかなんかを返せということを俺はいいたい
0599デフォルトの名無しさん2007/12/11(火) 02:01:03
君C#向いてないよ
0600デフォルトの名無しさん2007/12/11(火) 02:02:45
>>599
>>596のようにしない方がいい理由がなにかいえるのか？
0601デフォルトの名無しさん2007/12/11(火) 02:05:45
Try形式だと基本bool値しか返ってこないけど
エラーに関してもっと詳しい情報を渡したい時には>>596のスタンス的にはどういう方法をとるの？
戻り値？引数？
0602デフォルトの名無しさん2007/12/11(火) 02:06:52
あ、割り込んじゃったけど>>601≠>>599です
0603デフォルトの名無しさん2007/12/11(火) 02:08:06
>>601
outでエラーの詳しい情報をobjectにして戻すのがいいと思っているが
それこそ例外をoutで返したらいい
0604デフォルトの名無しさん2007/12/11(火) 02:15:27
.NetFrameworkでそういった作りになってる物があるかな。
0605デフォルトの名無しさん2007/12/11(火) 02:19:16
投げずに渡す、か
正直それは考えた事なかったな
0606デフォルトの名無しさん2007/12/11(火) 02:22:15
.NET FrameworkにはTryParseのような一部のものしかそういう設計をとっていない
それは誤りだが今さら変えられない
.NET Frameworkで例外を返すのが使い物になるのはそれが共通であり
プログラマなら大抵そのクラスの動作を知っているからだ
自作のクラスでそれをやるのは死亡フラグそのものだ
0607デフォルトの名無しさん2007/12/11(火) 09:47:13
日本語でおｋ
0608デフォルトの名無しさん2007/12/11(火) 10:17:45
文字列をint型にキャストするには
　int.Parse(hogehoge)
等の方法でやっていますが、
変換する型そのものを文字列等で指定する方法がありますでしょうか？
0609デフォルトの名無しさん2007/12/11(火) 11:43:08
結局Win32のカオス具合をなぞってるだけだな
0610デフォルトの名無しさん2007/12/11(火) 11:51:29
>>608
それはキャストじゃなくて型変換（Convert）だろ。
TypeConverter/TypeDescriptor でも使えば？
0611デフォルトの名無しさん2007/12/11(火) 12:25:54
>>606
TryParseは2.0になって利便性のために新たに付け加えられたのであって、
決して「誤り」ではないよ。
0612デフォルトの名無しさん2007/12/11(火) 12:28:32
outで返すとC#でしか使えないことないか？

パラノイア的に統一性に拘らないのであれば（というのは、これに病的に固執する奴っているからね）
値を返さないメソッドに関してだけ例外を返すようにする（返値が必要なのは普通に例外投げる）
というやり方の方が俺は好きだな。
06136112007/12/11(火) 12:28:47
>>606
TryXの使い方のガイドラインあるから読んどけ
http://msdn2.microsoft.com/ja-jp/library/ms229009(VS.80).aspx
0614デフォルトの名無しさん2007/12/11(火) 13:29:25
>>612
outが嫌なら戻り値用の構造体を作ったっていい
>>613
パフォーマンス上の理由なんてのは的外れだ
その例外がめったに起こらなければ起こらないほど
例外のキャッチし忘れは深刻なバグになる
起こるか起こらないか分からないようなエラーが起こるものが
通常のメソッドと見た目全く同じに用意されていて
エラーにそなえてtryで囲めというのは間違い探しをしろといっているようなものだ
単に無駄だ
バグであることが分かりやすくなるように設計するべきだ
0615デフォルトの名無しさん2007/12/11(火) 13:30:22
平日の昼間っから暇なんだなあ
0616デフォルトの名無しさん2007/12/11(火) 13:41:10
なんでここは3行にまとめられない奴ばっかりなんだろ
0617デフォルトの名無しさん2007/12/11(火) 13:57:19
例外のキャッチし忘れはむしろ深刻にはならない。
0618デフォルトの名無しさん2007/12/11(火) 14:09:17
めったにないことだけどある環境では100回に1回ぐらい例外が投げられることがある
catchしてないのにテストをすり抜けてパッケージソフトとして出荷されてしまった
どうなる？
0619デフォルトの名無しさん2007/12/11(火) 14:14:53
例外は絶対投げちゃダメ！とかTryParseは誤り！とか言う事が極端だな
共有すべき普遍的な知識と自分だけの信念は区別しないと
0620デフォルトの名無しさん2007/12/11(火) 14:16:17
そんな事言ってる人居たっけ
0621デフォルトの名無しさん2007/12/11(火) 14:18:28
>>619
TryParseは正しい
正しく呼び出してもエラーが起こりうる場合例外は投げるべきじゃない
とは言った
0622デフォルトの名無しさん2007/12/11(火) 14:27:16
ちなみにTry〜を使うべきだと俺が考えるものには
メソッドが成功するかどうかが自分のプログラムの状態以外の要因で決まるもの(ハードディスクとかNetworkとか)と
それが正しい呼び出しであるかをテストする機能も正しい使い方のうちに含むもの(TryParse)と二通りある
0623デフォルトの名無しさん2007/12/11(火) 14:33:13
ここふらっとスレなんだけど。
■ このスレッドは過去ログ倉庫に格納されています