考証照二三事(二)

這星期就要報名考試了,
還記得上次我第一次打008開電話去報名時,
是一個說中文但有英文腔的小姐接的,
(ps.好像會因打去的所在地不同,會有不同人接,
而且重點是,電話費是對方付的)
他在問資料的時候,我覺得我真是個大笨蛋,
像他問地址時,我居然還回問是台灣的嗎?
回想起來,真是……,
我想當時她心中會不會想說,
難道我是要問外國的嗎?

考証照二三事(一)

最近為了忙考証照,真的忙的亂七八糟,
除了重聽課程及複習外,也忙著找報名的方式,
我查到的第一個方式是打電話,不過繳費的方式,
就只有刷卡一種,而這種刷卡的方式,我覺得蠻危險的,
只報給他信用卡上的資料,這樣就好??
不用再經過什麼認証嗎?
或許會有人覺得我俗,沒用過信用卡,
其實信用卡我是有一張的,但因沒在用,
一張免年費的卡,老是被催繳年費,
火大,就停掉了,
也就是現在如要刷卡,我需向別人借,
當然,安全性就很重要了,
資料會外洩呀!!

認証&考試

要給自己一點壓力了,
要不然,最近的日子真的有點懶散,
也不是說沒在做事,而是事情多到不知要做什麼?
 
我預計從7月中開始,每週考一科,
這個一個月應該就可以改完,
這樣,我就可以進行我的下一步計劃了…
畢竟時間是不等人的,我也不年輕了呀!!

在win2003上裝mysql

好不容易在2003上裝好了apache及php,

但在mysql的方面又出了問題,

mysql的版本為4.1版,不過,再怎麼裝都不能和phpmyadmin 2.6.3版

合起來用,真是奇怪了……..

————————–解決方法如下:—————————

(1) 在開始 → 執行輸入"CMD"進入命令列模式。
(2) 輸入 "MySQL 路徑\bin\mysql -h localhost -u root -p"。(假設要重設root密碼) (3) 接著會出現 Enter Password:輸入安裝MySQL打的密碼。
(4) mysql>提示符號鍵入:SET PASSWORD FOR
(5) 再輸入:‘root’@’localhost’ = OLD_PASSWORD(‘新密碼’);
(6) 完成,現在就可以登入 phpMyAdmin 囉!

補充:只要是 MySQL 4.1.x 版無法連接都可照此方法試試。

————————–原因:—————————

因為新版的mysql編碼和php 4.3的編碼不相同

在win2003上裝apache

為了自己架個blog來玩玩,

詳細教學可參考:http://ying.homedns.org/wp/archives/2005/03/17/22/20/35/

因為我的iis有太多雜七雜八的東西,

所以我選擇使用apache做為我的web server,

但我在安裝時,只要把apache(版本為2.0.5.4)的port從預設值80改掉,

在service中的apache不只無法啟動,連找都找不到,

但設為80就ok了,

我iis的service都關掉了呀,

怎麼會這樣呢?

最後我是用default 的80port裝進去,

再去httpd.conf 改設定,

這是個bug嗎?

ASP之傳值問題

如果在input為checkbox的value中傳超過個一個以上的值到另一頁,

<input type="checkbox" name="xCheck" value="<%=rs("EID")%>,<%=rs("Name")%>,<%=rs("Pay")%>">

則在接收頁,要怎麼明確取得這些值呢?
方法是用陣列加迴圈

Ary = split(Request("xCheck"),",")

 j =1 ‘每筆陣列內有幾項資料(a,b,c)
 k=0 ‘跑每一筆資料的迴圈數(a(k))
 
 For i=0 to ubound(Ary)
  If j=3 then
          k=i-2
          
          EID = Trim(ARY(k))
          Name = Trim(Ary(k+1))
          Pay = Trim(Ary(k+2))

          ‘中間內容省略……….

      j=0
      end if
 j=j+1 
 next

談論主題VB, Delphi, BCB 和 C++/MFC 的抉擇 (下)

 

引述

VB, Delphi, BCB 和 C++/MFC 的抉擇 (下)

使用 MFC 和使用 VB 或是 JAVA 有很大的差別,最主要是程式設計者需要了解 WIN32 的運作模型, MFC 物件在使用時需要根據 WIN32 運作模型來操作,否則物件一律會以 ASSERT 失敗的下場來結束程式,例如:WIN32 視窗沒有真正開啟在螢幕之前,是不可以產生 Timer 物件的,也不能存取其 DC 結構,又如 C++ 的 MFC 物件和其相對應的 WIN32 物件是必須透過兩階段的步驟來建立連結的,如果沒有做第二個階段 Create 的動作的話, C++ 裡的物件是完全不能操作的等等。而物件類別的線上說明通常不見得會解釋 WIN32 的運作模型,這使得學習 MFC 的門檻更加提高。反之 JAVA 或是 VB 的包裝就比較完善了,程式設計者不太需要了解 WIN32 系統運作的細節, (除非在 VB 中你需要使用 WIN32 API 自行設計功能時你才需要去深入了解 WIN32 系統),就可以快樂地完成所要製作的視窗界面了,所有的細節都已經被包裝好了,有適當的初始值與固定的執行時機。從另一個觀點來看,包裝當然使得使用容易,但是功能也就受到限制,效率也會打一點點折扣,這些都是挑選軟體環境必須注意的事項。不過在評估 VB 和 MFC 時,相信功能及效率可能都不會是最大的考慮點,軟體的架構、軟體的生命期、維護性、擴充性、與重用性才是決定的關鍵。如果你只是寫單一一個具有視窗界面的程式,系統本身運作模型很單純,你根本也沒有打算維護或是擴充它,那當然用 VB 來撰寫,可以得到最快的成果,因為它本來就是一個所謂的快速程式發展 (Rapid Application Development, RAD) 的環境。

最後,物件導向原理、 C++ 程序式與物件式併存的騎牆派設計、 WIN32 的運作原理,這三者造成了學習 MFC 的超高門檻,熟悉的人真的少之又少,也使得商業性軟體在評估各項投資與可能的報酬時,更加傾向於 VB,如果說 VB 應用程式在軟體規格變更時需要投資很多的人力去進行更改或是重新設計,那麼也是軟體公司老闆該頭痛的事,對於眾多的 VB 程式設計員來說反倒是保住飯碗的大利多囉!? 這些經濟社會層面的角力,明顯與技術層面的認知相左,在這裡只能說 WIN32 死亡的時候, MFC 和 VB 都將無一倖免,但是 C++/MFC 應用程式還保有 C++ 物件式系統的核心,換個圖形界面平台還能很快地恢復運作,但是 VB 程式的話就得看微軟公司的意向了。

VB 4.0 放棄了對 16bit VBX 的支援而改支援 32bit OCX 曾經是很多 VB 設計者的夢靨,如今微軟也不打算再推出 VB 7.0 了, 2001 年改推出 VB.NET 來取代,微軟在 VB.NET 中加入了嚴格的型態檢查,加入了物件導向的支援,說真的, VB.NET 的學習門檻一定提高了許多,真的也不能稱它為 BASIC 了,那 Visual Advanced 如何?! 2000 年下半年微軟推出的 C# 也是另一個物件導向佔上風的表象,大家真的需要仔細去評量一下才是,趁著你還在學校,沒有工作/薪水的壓力,有老師和同學可以討論的時候,趕快學習物件導向的概念,不要以為工業界短視的狀況會是不會改變的,等到老闆撐不過去的時候,你終究還是犧牲者的。

附帶一提的是 Delphi 和 BCB 基本上都是 RAD,比起 VB 好一點的是一個基於物件導向的 PASCAL,另一個則是基於 C++,都有物件導向的支援,也都有嚴格的型態系統支援。

附註:學習 MFC 除了練功之外,有沒有什麼直接的好處呢?

我想應該是藉此學習 C++,學物件導向分析、設計、程式製作,學視窗系統運作的原理,直接設計繪圖,可以設計多緒程式,可以用 D3D, OpenGL,另外有一件事可以給大家參考的是幾乎在所有的嵌入式系統中 C++/C 都是標準的設計語言,沒有 VB 這樣的環境喔。

>> VB, Delphi, BCB 和 C++/MFC 的抉擇 (上)

談論主題VB, Delphi, BCB 和 C++/MFC 的抉擇 (上)

引述

VB, Delphi, BCB 和 C++/MFC 的抉擇 (上)

轉貼自 http://squall.cs.ntou.edu.tw/ (海大資工-丁培毅老師教學網站)

————————————————————————-

VB: Microsoft Visual Basic
Delphi: Objective Pascal with visualized environment by Borland International
BCB: Borland C++ Builder
MFC: Microsoft foundation class

這是一個我不太喜歡談的決策問題,一直很希望由資訊系出去的學生都能夠了解製作軟體的各種方法, Basic, C, PASCAL, FORTRAN 這些語言無疑是相當基本的了,但是程式語言還有功能式 (functional) 的,物件導向式 (object oriented) 的,宣告式 (declarative) 的,在各個應用領域中享有自己的一片天地,可以讓大家深入地感受到軟體的能力。

在現實面上,程序導向和物件導向算是比較一般化的,其中程序導向語言製作的軟體仍然佔有最大的應用市場,也許程序式的運作模型最能被大家接受,最容易隨性地發揮,與現今 von Neuman 架構機器最能夠匹配,也許物件導向的方法太過嚴謹、太過抽象,在這種狀況下真的很難去說服同學說其它沒有被市場廣泛接受的軟體方法中擁有無限的希望,用心、下些苦工去了解他們是不會讓你後悔的;想說得嚴重一點,沒有了解各種軟體方法的話,也許資訊系就白走一遭了,可是也深深地知道市場早已證明,許多的從業人員不需要知道軟體製作的各種奧祕,只要精通程序式/結構化的軟體方法,在工商業界中已經可以無往不利了,真的看不出 von Neuman 型態的計算機模型會很快地消失,會有所謂物件化的硬體模型嗎? 所以真的也不預期程序式的程式製作方法會像史前的恐龍一樣受迫消失。

那麼物件式模組化、與應用領域緊密結合、由下而上 (bottom up) 的軟體製作方法是不是就永遠限於大規模、大成本、複雜、專業的軟體呢? 這些方法會的人少,資源也少,就好像叫好不叫座的電影一樣,讓所有的影評不知道該執著於理想拼命鼓吹呢? 還是順應大眾的口味,大加討伐一番。

上程式設計課程時常常提醒大家用的是 C 語言而不是 C++,就是不喜歡讓同學在使用支援物件導向的語言 (例如 C++) 以程序式的方法製作軟體時,自以為是製作物件式的軟體,運用物件式的語言並無法保證你用物件化的方式來設計、規劃及製作軟體, (另一方面,運用不支援物件導向的語言寫的軟體仍然可以基於物件導向的方法來設計,只是程式設計者所要遵循的規則無法由編譯器來幫你檢查,而必須由程式設計者自己來實現,) 學習物件導向的軟體設計方法可以讓大家領略軟體製作時工程式的嚴謹過程,了解軟體中物件系統紮實可重用的根基。

使用 VB 設計視窗環境應用程式的軟體工作者很明顯地比使用 C++/MFC 來設計視窗環境應用程式的工程師多太多了,由表象上來分析,使用者多的軟體發展環境資源多、可以諮詢的人也多,要完成計劃的阻礙比較低,當然吸引更多的人來投入。很沮喪地說,我幾乎找不到用 VB 寫不出來的視窗應用程式, (講這句話時有一點像是說沒有用 Assembly 寫不出來的程式一樣),如果為了安慰自己而說某些系統的應用為了配合作業系統還是需要用 C/C++ 的話,那微軟還有 COM/ActiveX 的技術可以讓 VB 的應用程式設計者輕鬆地運用 C/C++ 程式設計者的產品,那為什麼要 C++/MFC??? 不會說是寫系統核心才用得到吧,那你我什麼時候才寫得到系統核心呢?

由設計軟體的方法來比較, VB 是架構在 Basic 這種型態並非非常嚴謹的程序式語言上,先天上就有容易學習的優點,製作時不需要做嚴謹的分析設計圖,撰寫程式碼時不需嚴謹地訂定界面,維護封裝,入門的門檻明顯地比 C++/物件導向的程式製作方法要低得多。由另一個角度來看,大多數人在使用 VB 來設計應用系統時應該都是由界面物件開始設計,也就是應用 VB 表單編輯器來設計人與機器間的界面,然後再應用事件驅動的視窗程式運作模型逐一填入各個界面所引發的程式動作,這是非常功能性的 top-down 程式設計, (因為用到了許多界面物件,又用到了事件驅動的概念,所以許多人覺得 VB 也是物件導向了,這是很大的誤會,大多數程式設計師在設計 VB 的程式時可能對 "快速地完成設計" 要比 "完整的分析目標系統的運作與組成" 要注重得多,物件系統中抽象化的功能物件恐怕更不是考慮的重點,沒有這些基本考量的程式決不會是物件導向的,物件導向的四大特性甚至都還沒有包含 "事件驅動" 呢。) VB 程式的設計方法可以說是由外而內的, (在設計使用者界面的雛型時相信是一個很有用的工具),反觀使用 C++/MFC 來設計物件式系統時,通常不會由使用者界面著手,一般是由應用領域中系統運作來開始分析,所分析設計出來的物件不見得是人機界面的物件,而是運作系統中的物件,例如在進出貨管理系統中,實體貨物都有其相對應的軟體物件,儲存/載運/處理實體貨物的機制中,所有的資料、人員也都是系統中的物件,實體機制中所有的動作都在軟體系統中模擬為物件的互動,這些物件構成了軟體系統的核心機制,其中軟體物件和人員之間的界面也就是人機的界面,通常會抽離出來由使用者的角度進一步地設計合理美觀的互動機制,這種設計方式比較是由內而外的,通常可以先使核心軟體模型完全地符合應用環境來運作,然後再替這個系統架構人機間的視窗圖形化界面。

VB 自從 4.0 以後也可以自定抽象的物件了,有了封裝的特性,據說也可以繼承了,那應該也算是支援物件導向的軟體產品了,終究像 COBOL, PASCAL, FORTRAN, Perl 等等程序化的語言也都有了物件化的版本,可是相信沒有太多的程式設計師運用這些物件導向的語言功能,如果要求使用 VB 的人要先學會這些物件導向的方法,然後再來設計視窗應用程式的話,恐怕使用 VB 的人就不會比使用 C++/MFC 的人多太多了,就以微軟推出的 C# (C Sharp) 語言來說,它的目標市場恐怕和 VB 必須要有相當大的區隔。

究竟什麼時候該選擇 C++/MFC 來作為視窗環境應用程式的發展工具呢? 依照我個人的看法,應該是在你有一個嚴謹分析、設計、製作的物件導向系統之後,而你希望替它加上 "有效率" 的視窗界面的時候,才會有此選擇,為什麼會強調 "有效率" 呢? 因為在 Windows 平台上當然以 C++/MFC 來使用其 API 時能夠最直接地完成界面設計,否則如果要考慮到移植性的話, Java 恐怕會是一個非常合乎成本效益的技術平台,只要寫過一次以後,在許多的平台上都可以使用完全一樣的程式碼。另外其實要製作一個物件導向系統的時候其實也不一定要使用 C++,有許多的評論闡釋為什麼 C++ 不是一個好的物件導向語言,最主要的原因其實還是因為 C++ 包涵了 C 的所有語法,因此也一併允許程式設計者使用程序導向的方式來設計程式,如此在 C++ 語言的設計上沒有辦法儘量協助程式設計者來設計出物件導向的程式,反而暗藏很多陷阱,使得程式設計者很容易寫出違反物件導向原則

What is DataRelation??

在ASP.NET中對於資料的處理,
由於DataSet的出現,
使得資料間的關聯不再只依賴SQL的語法,
而可改用DataRelation.

DataRelation的用法,同關聯式資料庫,
意即二個不同的Table,用key(欄位)進行一對多的關聯.

在DataSet中可容納多個DataTable,
而這些DataTable就可以靠著DataRelation連繫在一起,
後續就可以藉著DataView OR DataReader把資料DataBind進去

語法如下:

Dim dr as DataRelation
Dim parentCol as Datacolumn
Dim childCol as DataColumn

parentCol = ds .tables("customers").columns("customerID")
childCol = ds.tables("orders").columns("customerID")
dr = New DataRelation("custorders",parentCol,childCol)
ds.Relations.Add(dr)