這裡主要起作用的是三跟指標,所以還是先從指標動手:
新建3個mc,分別畫好長度不相同(*樣式自定)時針,分針,秒針.注意畫的時候那個小+,那是指標的圓心
一一拖到場景中,例項名分別為hours,minutes,seconds
習慣問題,場景中新建個action層.在第一幀中編輯指標動起來的指令碼:
mytime=new date();
hours=(mytime.gethours()-1)*30; //時針轉一圈12個小時,每小時30度;
minutes=mytime.getminutes()*6; //分針每分轉6度;
seconds=mytime.getseconds()*6 //秒針每秒轉6度;
//接著使用_rotation屬性:
setproperty("seconds",_rotation,seconds);
setproperty("minutes",_rotation,minutes);
setproperty("hours",_rotation,hours);
這就完成了一般指標,接著就是解決不連貫的問題
hours=hours+(mytime.getminutes()/2);
minutes=minutes+(mytime.getseconds()/10);
這就讓分針都一直在隨秒鐘慢慢地走
當然,這麼寫會有問題滴
完整的是:
onenterframe = function () ;
做乙個「懶惰」的程式猿
懶惰，算是本人的一大缺點，可是我發現，事物的兩面性在懶惰上得到充分體現。懶惰，並不是一無是處。本人編寫指令碼的原因有兩個 一是省事，不用每次敲那麼多東西。二是本人健忘，無法記得冗長的命令。就拿ipc的 來講，ipc 根資料夾中，有n多build 而每個build 資料夾下的內容，則全然相似，都有乙個...
做乙個programmer，而不做乙個coder
programmer是程式的思考者，而coder只是乙個執行者 勞心者製人，勞力者制於人 如果專案不緊的情況下，應該從需求做起，最好能夠窮盡所有的需求，遇到與別人模組互動的情況，規定好與別人互動的介面。然後才是開始設計，抓住需求當中的名詞，想想是否設計成為類，然後根據測試用例，來設計框架結構，至少要...
做乙個更好的程式設計師
1.做最壞的打算 不管你工作中使用哪種程式語言，第乙個任務就是你應該寫乙個用於列印錯誤的函式。2.為忘記做好準備 寫程式時，同時也寫好完整的注釋，以備你六個月後重新來讀這段程式還能再讀懂，並且你能夠通過它告訴所有人你的程式是如何實現的。3.文件 在你的程式 檔案中包含文件，並把它放到程式 的相應目錄...