C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

全過去ログを検索

<< 0 | 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 >>
■1903  Re[2]: 可変データの取得について
□投稿者/ あき坊 -(2007/03/08(Thu) 16:03:33)
    ■Blueさん、Pandoraさん に返信

    早急なレス有難うございました。
    configは大変勉強になりました。参考書等に記載がなかったものですから、、、つい。
    ちなみにINIファイルはC#では一般的に使用するものなのでしょうか?
    保持情報的にはタイマ値・DBアクセス文字列等を想定しています。
    宜しくお願いいたします。

    >もちろんC#でもVC++同様にGetPrivateProfileString等のAPIを使って
    >INIファイルを操作することはできます。


    >>VC使用時に可変データをINIファイルに持たせていましたが、C#ではその様なものはないのでしょうか?
    >
    > アプリケーションの設定情報を保持したいと考えているのであれば、
    > アプリケーション構成ファイル(App.config)を使用すれば良いと思います。
    >
    >
記事No.1898 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1904  Re[3]: 可変データの取得について
□投稿者/ Pandora -(2007/03/08(Thu) 16:30:45)
    > ちなみにINIファイルはC#では一般的に使用するものなのでしょうか?
    > 保持情報的にはタイマ値・DBアクセス文字列等を想定しています。

     INIファイルが一般的かどうかわかりませんが、指定されている保持情報の内容から判断すると、
     頻繁に変更される値ではないと思うのでアプリケーション構成ファイル(App.config)に保持する
     ほうが取得が楽だと思います。
     構成ファイルの値を取得するメソッド(ConfigurationManager.AppSettings)が用意されていますので。
記事No.1898 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1908  Re[3]: 可変データの取得について
□投稿者/ 一羽 -(2007/03/08(Thu) 17:18:49)
    No1903 (あき坊 さん) に返信
    > ちなみにINIファイルはC#では一般的に使用するものなのでしょうか?

    .NET Frameworkに、INIファイルにアクセスするためのクラスがないため、
    新規に作成するのでしたら.configを使うほうが面倒がありません。

    また、ちょっとソースが見つからないので申し訳ないのですが、
    INIファイルというもの自体が、古いWindowsとの互換性のために残っているだけで、
    使用しないことを推奨されていたように記憶しています。
記事No.1898 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1910  Re[4]: 可変データの取得について
□投稿者/ あき坊 -(2007/03/08(Thu) 17:29:08)
    No1908 (Pandora & 一羽 さん) に返信

    有難うございます!!
    何だかかなりスッキリしました。
    これから達人(?)の域に達するまで頑張ります。解決です!


    >INIファイルが一般的かどうかわかりませんが、指定されている保持情報の内容から判断すると、
    >頻繁に変更される値ではないと思うのでアプリケーション構成ファイル(App.config)に保持する
    >
    >ほうが取得が楽だと思います。
    >構成ファイルの値を取得するメソッド(ConfigurationManager.AppSettings)が用意されていますので。


    > .NET Frameworkに、INIファイルにアクセスするためのクラスがないため、
    > 新規に作成するのでしたら.configを使うほうが面倒がありません。
    >
    > また、ちょっとソースが見つからないので申し訳ないのですが、
    > INIファイルというもの自体が、古いWindowsとの互換性のために残っているだけで、
    > 使用しないことを推奨されていたように記憶しています。
    >
記事No.1898 のレス / END /過去ログ10より / 関連記事表示
削除チェック/

■1915  FTPプログラムの作り方
□投稿者/ mako -(2007/03/08(Thu) 18:39:16)

    分類:[VB.NET (Windows)] 

    VB.NETでFTPプログラムを作成しようとしています。
    FTPについて触れた本がないため、どうすればよいのか悩んでいます。
    詳しい方教えてください。。。
親記事 /過去ログ10より / 関連記事表示
削除チェック/

■1917  Re[1]: FTPプログラムの作り方
□投稿者/ Pandora -(2007/03/08(Thu) 18:44:23)
記事No.1915 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1921  Re[2]: FTPプログラムの作り方
□投稿者/ ぽぴ王子 -(2007/03/08(Thu) 18:57:13)
>
    No1915 (mako さん) に返信
    > VB.NETでFTPプログラムを作成しようとしています。
    > FTPについて触れた本がないため、どうすればよいのか悩んでいます。
    > 詳しい方教えてください。。。

    FTP と言っても FTP サーバーと FTP クライアントがあるわけですが、どちらを作成し
    たいのでしょう。
    FTP クライアントであれば、Pandora さんが挙げてくださったサイトが参考になるかと
    思いますが、サーバーだとちょっと難しいような…(普通はサーバーなんて作らない?)

    というかですね、なぜ FTP プログラム(クライアントと仮定します)を作ろうと思われ
    たのかがちょっと疑問だったり。
    FTP について触れた本がない→ FTP についてそんなに詳しくは知らない
    ということだと思うのですが、FTP について詳しくない方がなぜ FTP プログラムを作
    成しようと思われたのか、よろしければその理由などを教えていただけるとありがた
    いです。
記事No.1915 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1919  Re[2]: FTPプログラムの作り方
□投稿者/ mako -(2007/03/08(Thu) 18:53:55)
    Pandoraさん、ありがとうございます。
    教えていただいたサイトを参考にがんばってみます。
記事No.1915 のレス / END /過去ログ10より / 関連記事表示
削除チェック/

■1886  HashTableについて
□投稿者/ ちぃ -(2007/03/08(Thu) 10:55:15)

    分類:[VB.NET (Windows)] 

    現在Microsoft Visual Basic .NET 2003 で開発をしています。
    そこで、HashTableに関して質問なのですが、
    下記のようなキーと値を順にHashTableに格納していくと、
    構造はこうなります。

    キー:値
    aa :1
    bb :2
    cc :3
    dd :4

    HashTable:htに格納すると、
    ht-(0)key:cc
    | val:3
    -(1)key:aa
    | val:1
    -(2)key:bb
    | val:2
    -(3)key:dd
    val:4
    上記のように、インデックスがバラバラになってしまいます。
    これを、
    ht-(0)key:aa
    | val:1
    -(1)key:bb
    | val:2
    -(2)key:cc
    | val:3
    -(3)key:dd
    val:4
    格納した順にインデックスを振ることは不可能ですよね?
    いろいろ調べ無理そうでしたが、はっきり無理とわかれば
    諦めもつくので、よろしくお願いします。
親記事 /過去ログ10より / 関連記事表示
削除チェック/

■1889  Re[1]: HashTableについて
□投稿者/ シャノン -(2007/03/08(Thu) 11:09:21)
    No1886 (ちぃ さん) に返信
    > 格納した順にインデックスを振ることは不可能ですよね?

    はい。
    Hashtableはアイテムの順序を保証しません。

    キーがstringでいいなら、NameObjectCollectionBaseの派生クラスを作ればいけるかも。
    キーも任意の型にしたい場合でも、順序を記憶するコレクションを自作することはできるでしょう。
記事No.1886 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1887  Re[1]: HashTableについて
□投稿者/ はつね -(2007/03/08(Thu) 11:07:04)
>
    No1886 (ちぃ さん) に返信
    > 現在Microsoft Visual Basic .NET 2003 で開発をしています。
    > そこで、HashTableに関して質問なのですが、
    > 下記のようなキーと値を順にHashTableに格納していくと、
    > 構造はこうなります。
    >
    > キー:値
    > aa :1
    > bb :2
    > cc :3
    > dd :4

    HashTableとはHash関数によりキー値を対応するHash値に変換する事で、キーを指定してテーブルの中から1つのものを効率よく取り出すための仕組みです。そして、このHash関数は「入れた順番をIndexにする」というような仕組みにはなっていませんので、ご希望の動作はできません。
記事No.1886 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1890  Re[2]: HashTableについて
□投稿者/ ちぃ -(2007/03/08(Thu) 11:12:08)
    > HashTableとはHash関数によりキー値を対応するHash値に変換する事で、キーを指定してテーブルの中から1つのものを効率よく取り出すための仕組みです。そして、このHash関数は「入れた順番をIndexにする」というような仕組みにはなっていませんので、ご希望の動作はできません。

    そうですよね。
    キーを指定して値を取り出せるのが利点ですもんね。
    他のコレクションで考えたいと思います。
    ありがとうございました。
記事No.1886 のレス / END /過去ログ10より / 関連記事表示
削除チェック/

■1891  Re[3]: HashTableについて
□投稿者/ ぼのぼの -(2007/03/08(Thu) 11:19:04)
    スマートな方法かどうかはわかりませんが、
    以前、クラスを自分で作るのがめんどくさかったので、
    1行のDataTableで代用したことがありました。
    
    Dim dt As New DataTable
    dt.Columns.Add("aa")
    dt.Columns.Add("bb")
    dt.Columns.Add("cc")
    dt.Columns.Add("dd")
    Dim dr As DataRow = dt.NewRow()
    dr("aa") = 1
    dr("bb") = 2
    dr("cc") = 3
    dr("dd") = 4
    
記事No.1886 のレス / END /過去ログ10より / 関連記事表示
削除チェック/

■1894  Re[4]: HashTableについて
□投稿者/ aoa -(2007/03/08(Thu) 12:41:50)
    2007/03/08(Thu) 12:56:35 編集(投稿者)

    こんにちは

    手抜きですが、私ならこのようにして
    HashTableを継承したクラスにToArrayメソッドを持たせます。
    Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    Dim table As New Hashtable()
    With table
    .Add("aa", New Item(1, 0))
    .Add("bb", New Item(2, 1))
    .Add("cc", New Item(3, 2))
    .Add("dd", New Item(4, 3))
    End With
    Dim arr(table.Count - 1) As Object
    Dim counter As Integer = 0
    For Each obj As Object In table.Values
    arr(counter) = DirectCast(obj, Item)
    counter += 1
    Next
    Array.Sort(arr)
    End Sub
    End Class

    Public Class Item
    Implements IComparable
    Private _index As Integer
    Private _value As Object
    Public Sub New(ByVal value As Object, ByVal index As Integer)
    Me._index = index
    Me._value = value
    End Sub
    Public ReadOnly Property Value() As Object
    Get
    Return _value
    End Get
    End Property
    Public Function CompareTo(ByVal obj As Object) As Integer Implements System.IComparable.CompareTo
    Dim other As Item = DirectCast(obj, Item)
    Return Me._index - other._index
    End Function
    End Class


記事No.1886 のレス / END /過去ログ10より / 関連記事表示
削除チェック/

■1924  Re[5]: HashTableについて
□投稿者/ なちゃ -(2007/03/08(Thu) 19:35:22)
    2005ならOrderedDictionaryっていうほぼそのままの機能があるんですけどね…
記事No.1886 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1778  アプリケーション作成時に機能別にexeを分けていますか?
□投稿者/ ばこま -(2007/03/06(Tue) 10:14:31)

    分類:[Windows 全般] 

    2007/03/06(Tue) 10:14:51 編集(投稿者)

    こんにちは、ばこまです。連続投稿失礼します・・・

    今C#にて画面が40個程度のWindowsアプリケーションを作成していますが、色々調べてみたら
    exeを機能別に分けている方法が多いような気がします。
    exeを機能別に分けるメリット、デメリットとは何でしょうか?

    個人的には分けない方がデータの受け渡し、画面起動がスムーズに行えるような気がしますが…

    それではよろしくお願いします。

親記事 /過去ログ10より / 関連記事表示
削除チェック/

■1780  Re[1]: アプリケーション作成時に機能別にexeを分けていますか?
□投稿者/ M.K -(2007/03/06(Tue) 10:37:46)
    No1778 (ばこま さん) に返信

    > exeを機能別に分けるメリット、デメリットとは何でしょうか?

    機能別に全部exeにしてしまうとばこまさんの仰る様にデータの受け渡しや画面起動
    の点でちょっと大変かも知れませんが、メニューなどから起動されるメイン画面のみ
    exeとし、そこから呼ばれるサブ画面などはdllにする事でその辺りの問題は改善され
    ると思います。

    その上で個人的にパッと思いつくメリット・デメリットです。

    メリット:

     多人数で並列して開発が出来る。
     機能毎にモジュールの処理が完結しているので再利用性が高い。
     加修を行った際に他のモジュールへの影響度合いが低い。
     1アセンブリのファイルサイズを小さくする事が出来る。

    デメリット:

     作り方によっては起動時のオーバーヘッドが大きくなる。
     個々のアセンブリのバージョン管理が必要になる。
     ファイル数が多くなるので、プログラム名やソースなど管理が大変になる。
     参照設定が複雑になり過ぎてかえって加修時の影響度が大きくなる場合もある。

    それぞれに一長一短があると思うので、開発規模や開発ルールに則ってどちらが
    良いかを選択すればよいかと思います。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1783  Re[2]: アプリケーション作成時に機能別にexeを分けていますか?
□投稿者/ 未記入 -(2007/03/06(Tue) 11:28:03)
    No1780 (M.K さん) に返信
    >  ファイル数が多くなるので、プログラム名やソースなど管理が大変になる。
    >  参照設定が複雑になり過ぎてかえって加修時の影響度が大きくなる場合もある。

    これはありえないかなぁ。
    ファイル数が多くなるのと、ソースが複雑になるのとではわけが違うのでデメリットになるのかな。と。

    バージョン管理については、どこにいってもデグレードさせる人がいるので、VSSで管理します。
    というより、VSSで管理しておけばあまり問題にならないでしょう。

    あとの意見は概ね賛成。
    データの受け渡しに関しては、RDBMSなどで行えばいいでしょう。

    小規模でもない限り分けた方が良いに1票。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1798  Re[3]: アプリケーション作成時に機能別にexeを分けていますか?
□投稿者/ 中博俊 -(2007/03/06(Tue) 19:18:41)
>
    EXEを画面単位にわけるってこと?
    おいらは反対。
    EXEは1つでやるべき。
    DLLは好きにしてちょ。

    よく認証、認可でメニューを切り替えますとか言って、メニューEXEにしか対策されていなくて、単独EXE起動すれば使えるとかお茶目なアプリがあったりします。

    もちろんEXEが分かれているとプロセスが分離するので、データのやり取りが大変ってのがありますね。

    EXEはあくまでエントリポイントとしての分割単位にとどめたほうがいいと思います。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

■1801  Re[4]: アプリケーション作成時に機能別にexeを分けていますか?
□投稿者/ はつね -(2007/03/06(Tue) 21:12:58)
>
    Windows全般という事ですが、私の場合は.NET以降かでちょっとだけ異なります。

    基本は機能単位にアセンブリを作るという事です。

    ただし、VB6までの場合はアセンブリ=EXEにしています。このとき注意していたのは単独で起動されたとしても問題ない範囲でEXEを分けることでした。
    .NETでは、もう少し柔軟にしており、起動する部分はEXEでそれ以降はDLLになっていたりもします。

    アセンブリが増えるとコンパイル時間などの問題もあるでしょうが、修正したファイルが含まれるプロジェクトだけコンパイルすればいいのですから、実際はアセンブリの数というよりも再コンパイルが必要な範囲に依存すると思います。きちんと設計すればするほど影響範囲が狭まりますから、コンパイル時間を気にしてアセンブリを分けるのを躊躇する必要はないと考えます。
記事No.1778 のレス /過去ログ10より / 関連記事表示
削除チェック/

<前の20件 | 次の20件>

<< 0 | 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 >>

ヒット件数が多いので過去ログ1〜10 までの検索結果 / 過去ログ11からさらに検索→

パスワード/

- Child Tree -