none
VB語法的 IsNumeric,發現C#語法好像沒有對應的用法?? RRS feed

  • 問題

  • If IsNumeric(args.Value) = False Then

       .....................

    End If

     

    請問一下 VB語法的 IsNumeric

     

    我查了GOOGLE之後,發現C#語法好像沒有對應的用法

    該怎麼辦呢?

     

    2008年10月10日 上午 11:30

解答

  • IsNumeric, IsDate, IsNothing... 這些都是 VB 的專屬語法, C# 沒有。不過我們其實可以從 C# 去呼叫 Microsoft.VisualBasic 命名空間下的許多方法, 除了把 Microsoft.VisualBasic.dll 匯入網站參考之外 (就算你的網站一開始就使用 VB 在開發, 一樣要做這個動作), 再於程式最上方加上 using Microsoft.VisualBasic; 然後就可以使用 Information.IsNumeric、Informatioin.IsDate 等等了。當然, 不是只有這些, 還有別的 (例如 DateAndTime.DateDiff 等), 不過不是全部 (例如 Left、Mid、Right 等)。

    2008年10月10日 下午 02:50
  •  A.W. 寫信:

    If IsNumeric(args.Value) = False Then

       .....................

    End If

     

    請問一下 VB語法的 IsNumeric

     

    我查了GOOGLE之後,發現C#語法好像沒有對應的用法

    該怎麼辦呢?

     

     

    使用C#的朋友,您把下面這個函數放在程式碼最後,

    就可以使用 IsNumeric了

     

    微軟出品的,用起來應該有信心

     

        // IsNumeric Function
        // 資料來源:
    http://support.microsoft.com/kb/329488/zh-tw
        static bool IsNumeric(object Expression)
        {
            // Variable to collect the Return value of the TryParse method.
            bool isNum;

            // Define variable to collect out parameter of the TryParse method. If the conversion fails, the out parameter is zero.
            double retNum;

            // The TryParse method converts a string in a specified style and culture-specific format to its double-precision floating point number equivalent.
            // The TryParse method does not generate an exception if the conversion fails. If the conversion passes, True is returned. If it does not, False is returned.
            isNum = Double.TryParse(Convert.ToString(Expression), System.Globalization.NumberStyles.Any, System.Globalization.NumberFormatInfo.InvariantInfo, out retNum);


            return isNum;
        }

    2008年10月13日 上午 02:13

所有回覆

    • 已提議為解答 Peter177 2009年10月23日 上午 04:22
    2008年10月10日 上午 11:36
  • IsNumeric, IsDate, IsNothing... 這些都是 VB 的專屬語法, C# 沒有。不過我們其實可以從 C# 去呼叫 Microsoft.VisualBasic 命名空間下的許多方法, 除了把 Microsoft.VisualBasic.dll 匯入網站參考之外 (就算你的網站一開始就使用 VB 在開發, 一樣要做這個動作), 再於程式最上方加上 using Microsoft.VisualBasic; 然後就可以使用 Information.IsNumeric、Informatioin.IsDate 等等了。當然, 不是只有這些, 還有別的 (例如 DateAndTime.DateDiff 等), 不過不是全部 (例如 Left、Mid、Right 等)。

    2008年10月10日 下午 02:50
  • 既然都要用 C# 了,請把 VB 的函數都忘掉。

    引用 Microsoft.VisualBasic 命名空間雖然很方便,但無助於學習與操作 C# 和 Class Library。

     

    2008年10月10日 下午 03:44
    版主
  • 呵呵, VB 在很多地方都很方便哩! 我們 MVP 有兩位在他們的書裡花了很大篇幅在介紹如何在 C# 裡引用 VB 的函數... 怎麼能忘掉 VB 呢?

     

    2008年10月10日 下午 03:47
  • 方便是一回事,嚴謹又是一回事。VB 就是把東西包的太好了 (ex. My 物件),讓一堆 VB Programmer 轉到 C# 時發生問題,而且幾乎都是 VB 可用,C# 不能用的函數,如果整天在想 C# 怎麼用 VB 的函數,而忽略掉 Class Library 的基本用法,那乾脆就回去寫 VB 就好了,幹嘛要跳到 C#?

     

    很多問題都是因為太方便才會產生 ...
    2008年10月11日 上午 01:36
    版主
  • 這個問題討論到這邊其實有點怪。

     

    我是覺得自己想怎樣玩就怎樣玩,那是個人的問題,不用太在乎。

     

    從根本來看,應該說是程式設計師的「潔癖」,希望寫出來的程式碼所需仰賴的東西越少越好。

     

    但是程式設計師又常因為整合使用很多免費或要錢的協力廠商開發元件或技術,所以常有開發出來的程式碼又必須牽拖一堆。

     

    又或者自己用 C# 開發出 IsNumeric 等一堆自己常用的類別庫後,結果變成要多綁一段自己的原始碼或是自建的類別庫。

     

    從這個角度來看,Microsoft.VisualBasic 畢竟是 .Net 內建類別,它的依賴性頂多是虛要參照到這個命名空間,反正很多 .Net 類別在用起來也必須參照到對應的空間,看起來似乎沒那麼可惡,從廣義的角度,把他當成另一個 .Net 類別也可以。甚至很多人為了用只有在 Java 命名空間下才有的 Eval / Zip ,還特別在 VB/C# 中參照 Microsoft.JScript ,這種範例也是一堆,總不會在 C# 參照 JScript 就是技術,參照 VB 就是罪惡吧?

     

    但若是跨平台呢?比如說利用 Mono Project 跨到 Linux / Mac 等,我印象中 Microsoft.VisualBasic 要另外裝 Basic 套件,這樣感覺上就比較有影響。

     

    另外,跟同事間交接程式碼或是共同開發時,這也會產生影響,不過這是開發小組本身要先定義的設計基本原則,那種情況下到底可不可用就是專案經理決定了。

     

    而談到依賴性,就要比 VC 跟 C# 的差異,而 C# 本來就是 C 中的 VB ,本來就是為了快速開發來使用,而回頭來看,為了快速開發,在 C# 中用 VisualBasic 命名空間也沒啥不可以的。

     

    說了一堆廢話後,我要說的重點:

    自己爽就好

     

    每個人對程式碼的要求不同,闡述個人的想法就可以了,好壞自己各自評量,這個東西沒有絕對的對錯問題,只是取捨,怎樣選擇是個人問題,自己覺得好就好,當然老闆最大,不要跟老闆辯論你的程式碼撰寫原則,除非你有捲鋪蓋走人的心理準備。

    2008年10月11日 上午 06:11
  • 我以前的公司用 VB, 現在的公司用 C#, 在家裡則是兩者都有。其實也不會 "整天在想" 怎麼在 C# 去偷用 VB 的函數, 因為真正實用的也不過那幾個。倒是時常很 "肖想" 在 VB 裡用到 C# 的方便功能, 例如 @ 跟 int?。以前更垂涎三尺的是 ///, 還好後來 VB 有補上 '''。

     

    至於忽略掉 Class Library 的基本用法... 我覺得還好啦, 不會用的還是不會去用, 我從來也不覺得寫 C# 比寫 VB 高明; 如果觀念不對, C# 也可以寫得比 VB 糟糕十倍, 不是嗎?

    2008年10月11日 下午 12:49
  • 如果要這樣想,就沒什麼好討論的了。反正前面就已經有答案了:自己爽就好。

     

    我要強調的,是既然轉了一個語言,就不要老在前一個語言的語法和函數中打轉,浪費時間又不見得有效果(就像在 C++ 中找 VB 的 IsNumeric 一樣),如果一直要在這個地方打轉,那不如不要轉,反正 VB 和 C# 共用一套 Framework。基礎類別庫不會使用,等於鑰匙在你手上卻不會開鎖一樣,我不認為不會用基礎類別庫的東西能寫的出好程式,不然就是花十倍以上的時間,才發現原來類別庫中已經有的用了。

     

    我也很喜歡方便,所以我會寫很多類別來幫我處理很多事情,只要辛苦一次就可以解決很多問題,就算發生問題了,原始程式碼也在自己手上可以解決,就像璉大也寫了很多 VB 函式,現在他也就不必辛苦花時間在同樣的東西上了。

     

    還有,沒人說寫 C# 比寫 VB 高明,就這樣。

    2008年10月11日 下午 05:18
    版主
  • 其實我曾經以使用者身分向微軟建議在 C# 加上 VB 裡面好用的功能, 以及在 VB 裡加上一些 C# 功能。當然, 看樣子微軟並沒有全部接受。不過 Information.IsNumeric, Information.IsDate 等等確實很好用 (能正確辨識不同文化特性 (如全形/半形/上午/下午/AM/PM/年月日/月日年及許多我們不知道的格式) 的數字及日期格式等等), 又不必花太多 effort, 不用白不用!  ;-)

     

    當然啦, VB 裡面的 My 捷徑我連寫 VB 都是不用的 (呃... 是很少用), 不用提 C# 了。

    2008年10月12日 上午 05:13
  •  A.W. 寫信:

    If IsNumeric(args.Value) = False Then

       .....................

    End If

     

    請問一下 VB語法的 IsNumeric

     

    我查了GOOGLE之後,發現C#語法好像沒有對應的用法

    該怎麼辦呢?

     

     

    使用C#的朋友,您把下面這個函數放在程式碼最後,

    就可以使用 IsNumeric了

     

    微軟出品的,用起來應該有信心

     

        // IsNumeric Function
        // 資料來源:
    http://support.microsoft.com/kb/329488/zh-tw
        static bool IsNumeric(object Expression)
        {
            // Variable to collect the Return value of the TryParse method.
            bool isNum;

            // Define variable to collect out parameter of the TryParse method. If the conversion fails, the out parameter is zero.
            double retNum;

            // The TryParse method converts a string in a specified style and culture-specific format to its double-precision floating point number equivalent.
            // The TryParse method does not generate an exception if the conversion fails. If the conversion passes, True is returned. If it does not, False is returned.
            isNum = Double.TryParse(Convert.ToString(Expression), System.Globalization.NumberStyles.Any, System.Globalization.NumberFormatInfo.InvariantInfo, out retNum);


            return isNum;
        }

    2008年10月13日 上午 02:13
  • 哎呀 有那麼麻煩嗎 ?
    小弟覺得 程式一直寫 寫久自然就會建立出很多 自己的專屬"類別庫"了
    以後遇到類似的狀況  直接Copy Paste就好 或直接引用
    這個跟元件沒太大關係了 . 而是經驗來判定的 ...
    如果有看到比自己寫的更好的代碼 可以拿來當參考修改

    大家應該都很清楚物件導向的概念 尤其愛用MFC的
    舉例 : 有時候 丟給你一個"Case" 叫你做一個桌子
    但是你之前就有做過桌子的經驗 桌腳 桌面 螺絲等等 都有現成的了
    那就組合一下 不就馬上好了 ? 如果是叫你換顏色 那頂多重刷一個顏色而已

    就像上面判定數字  0 ~ 9 如果還加上小數點等 ASCII也沒幾個碼
    也還有2進位可以判斷的 如果是特殊目的 可以辛苦一點寫玩一次就好
    其實也花不了多少時間 以後就這樣調用就好

    如果沒有啥特別想法或單純只想簡單完成工作 那翻一下MSDN或Search一下網頁 基本上都會有答案的
    就像下面網友寫的簡單編碼轉換代碼
    以上個人想法 ...

      void UTF8ToUnicode(wchar_t* pout,char *ptext)
      {
       char* uchar = (char *)pout;  
       uchar[1] = ((ptext[0] & 0x0F) << 4) + ((ptext[1] >> 2) & 0x0F);  
       uchar[0] = ((ptext[1] & 0x03) << 6) + (ptext[2] & 0x3F);  
       return;
      }
    2009年9月30日 上午 08:58
  • 建議.net framework有的library就先找,先用...

    自己寫當然也可以,這倒不是難不難的問題,
    而是用.net framework的好處比較多。

    一來有最佳化,二來不用擔心責任問題,
    就如同之前有人說,民國年就用西元年-1911就好,為啥還要用culture和library。
    當客戶argu 西元1911年是民國0年還是民國前1年的時候,就可以把說法推給.net framework...

    省得自己講再多,人家都當作可能是bug

    2009年9月30日 上午 09:13
    版主
  • C#,C++,傻傻分不清楚...
    初學不是問題,但用不正確的態度來問問題,那就是很大的問題。
    如果只會用 "看" 的學程式,那不如早點改行,以免誤己一生...
    若不想快點得到解答,可以儘量把問題寫模糊一點,愈模糊愈不會得到解答。
    2009年9月30日 上午 09:36
    版主
  • 請問"那句話" 在說誰 ?
    C# 難道一開始有這種語言嗎
    VC.NET/VB.Net是用什麼原始語言開發出來的 請不要把點搞錯
    它的本意基礎是面向平台開發便利 類似以前的BC / VB 和 MFC比
    使用這種語言就要捨棄或忘記其他語言 就只用它內建的Class就好?
    那微軟也不需要出C# 或 F#了 專案類別庫的地方也可以都丟掉了
    反正都只要按個 . 或 ::或->就OK  那程式滿分 Case趕出來就好
    不可否認 如果很精通 .Net 的用法
    寫出一個好的專案是很便利且時間根本跟用一些低階語言比 可以不分軒輊
    (但這是不可能的 頂多只有時間優勢和商業趨勢)
    就像之前在我的FaceBook留言版提到的文章部分
    ////////////////////////////////////////////
    並不是說用C#不好 我也常用C#寫程式(因為方便)
    現在很多企業或用戶 Case都是只看結果不看過程的
    所以精通C#並無壞處 .........
    在這種競爭的社會 軟體程式設計師 應該不能不會
    至於要不要更深入研究...... 那都是看個人的興趣
    例如C# - > VC -> C -> ASM
    當然一個大型商業軟件的開發
    幾乎可以說沒人會用那些高級語言寫 .....
    /////////////////////////////////////////////
    反正我說出想法的發言  大概就是被圍剿
    結論就是上面心冷大說的那幾個紅字 
    為何我很多發言 幾乎都只有提示 很少會寫出完整的答案
    我的本意是希望 問答者 可以藉著這個線索
    不僅找到需要的答案 還可以吸收更多意外的資訊
    如果認為上面的發言亂扯 就當亂扯 ...
    其它就隨意...沒意見
    2009年9月30日 上午 11:10