電波幻想

噓.....此程式請勿廣傳，因為有廠商靠這個吃飯 透過此程式來判斷郵遞區號 下載處： https://tinyurl.com/6fkv2hfk 解壓縮密碼：我愛電波 需要環境： .Net Framework 3.5 使用方式： TZIP32.exe InputFile OutputFile [-icpCodeName] [-ocpCodeName]   InputFile   輸入檔案   OutputFile  輸出檔案   -icp        選擇性，輸入檔案編碼，例如：big5,utf8,ansi....，不輸入則以系統預設編碼為主   -ocp        選擇性，輸出檔案編碼，例如：big5,utf8,ansi....，不輸入則以系統預設編碼為主 範例： TZIP32.exe in_address.txt out_address.txt TZIP32.exe 主程式 in_address.txt 需要判斷的地址資料(可以單筆/多筆，檔名不設限，需為文字檔) out_address.txt 判斷結果輸出檔案(依照輸入檔案，逐行產生，前5碼為郵遞區號) 注意： 1、輸出檔案產生前須先刪除，避免系統咬住 2、輸出檔案產生前會先產一個暫存檔，通常為輸出檔的附檔名最後一個字元變成底線     例如：out_address.tx_ → out_address.txt 3、程式中有個DBF資料夾，它是郵局3+2的DBF，如要更新可以直接去下載郵局3+2的資料庫檔案直接更新即可。 底下為輸出範例 in_address.txt 高雄市林園區鳳林路１段１號４樓 台北市中正區新生南路一段５８巷１２－１號２Ｆ 台北市新生南路一段１３８號６樓之１ 臺北市大安區敦化南路２段１７０號２樓 台北市大安區復興南路一段１４４號 台北市信義區信義路５段１５０巷３３２號１３樓 苗栗縣竹南鎮博愛街２１７號５樓 台北市中山區南京東路２段２號９樓 桃園市桃園區中山路８４５號６樓 桃園市桃園區中山路８４５號９樓 台北市大安區敦化南路１段１１１號１２樓 台北市大安區信義路四段２９６號７Ｆ－２ 臺北市中正區羅斯福路１段９巷２弄１２號１樓 台北市木柵路一段３３１－９號 新北市新店區寶橋路２３５巷１２９號２Ｆ 台北市文山區萬芳路４０號 台中市北區進化

This is a simple tools for display keyboard LED status & HDD read-write status . 這是一款簡單顯示鍵盤LED狀態與硬碟讀寫LED狀態的應用程序。 Most wireless keyboards do not have special key LED display, such as Caps Lock, Scroll Lock, Num Lock . 大部分無線鍵盤都沒有特殊鍵LED顯示，例如Caps Lock , Scroll Lock , Num Lock 。 Or on the remote desktop - maybe it’s different from the keyboard on the remote . 或是在遠端桌面 - 也許和遙控端的鍵盤狀態不同 It runs on .Net Framework 4.5, please make sure your environment supports it 它是運行在.Net Framework 4.5，請先確認您的環境有支援它 Download .net framework 4.5 here :  下載.et framework 4.5 套件：     https://www.microsoft.com/zh-tw/download/details.aspx?id=42642 Download SystemLED tool : 下載 SystemLED 程序：      https://drive.google.com/file/d/1eAF3vXgHqCEr5u09Nysqq8SzQCZ7KuDF/view?usp=sharing zip password (解壓密碼) : https://radio-idea.blogspot.com You can move position everywhere on your desktop , and click right button to close . 您可以在桌面任意位置移動位置，然後單擊右鍵關閉。

 對不起，管理員 因為公司強迫要求使用者未使用電腦情況下，5分鐘要鎖定螢幕，由於是使用AD強制控制，所以使用者沒有辦法自己去關閉。 而我，因為常有需要參考畫面上的內容，在另外一部電腦操作，因此導致這部電腦一直會進入螢幕鎖定。超級麻煩又討厭。 所以開發了一隻小程式來防止Windows進入螢幕鎖定狀態。   程式下載(我只想使用)： 這裡   密碼：radio-idea.blogspot.com   平台：.Net FrameWork 4.5   注意：可能會與軟體KVM衝突 這是利用Timer不斷偵測 Idle 時間 而這個 Idle 時間則是利用 GetLastInputInfo 取得鍵盤滑鼠輸入的最後時間計算與現在的時間差得到的，當這個時間差超過預定檢測的時間(我的程式碼是設定4分鐘，因為進入螢幕鎖定是5分鐘)時，會去模擬滑鼠輸入動作，這個模擬動作是透過SendInput來達成，以上這些功能都是呼叫Windows API來處理。 由於Windows API是非託管程序(Unmanaged)因此得引用 using System.Runtime.InteropServices; 主程序： using  System; using  System.Windows.Forms; using  System.Runtime.InteropServices; using  System.Configuration; namespace  DONTSLEEP {      public partial class   Form1 : Form     {          public int  Idle_time = 240; //閒置秒數(4分鐘)          public int  CCount = 0;          public bool  shacking =  false ;                   public enum   MonitorState   : int         {             MONITOR_ON = -1,             MONITOR_OFF = 2,            

Turnkey 是財政部電子發票平台的一套傳送工具 說真的，這套工具還蠻陽春的，對於有獨立伺服器的公司來說，不是很好用。 首先，它必須在使用者登入的桌面中執行，無法作為服務使用 其次，它執行排程時，背後一堆開啟的視窗不能關掉 最後，處理狀況的查詢，只能在該機器上直接查詢，無法透過遠端查詢(這個真的麻煩，尤其伺服器不能隨便把帳號密碼給使用者) 這次會開發這個工具的原因在於， 財務單位她們有自己的系統會產生傳給Turnkey的XML檔案，並直接丟到Turnkey處理的資料夾下 有時後，財務的系統沒有正常產生，導致電子發票平台一直沒收到資料，搞到去懷疑Turnkey主機有問題。 因此，特別開發這樣的程式來檢測Turnkey處理資料夾下是否有檔案被丟進來，並且整理後發郵件告知使用者。 先看看Turnkey處理資料檔案的類型與結構 相對於Turnkey處理黨案的預設路徑在 C:\Program Files\EINVTurnkey\UpCast 該路徑下的資料夾結構會有對應的名稱 下面還有分類資料夾： 每個分類資料夾下還會有3個資料夾，分別是SRC、BAK、ERR 通常新進來的檔案都會放在SRC裏面，經由Turnkeyt處理以後會從SRC移除並分類放在BAK和ERR裏面 所以這支程式就是專門在偵測SRC的檔案出現，並收集檔案名稱並以郵件回報給相關使用者 程式名稱：TKReceiveDetect.exe ( 下載 ) 環境需求：dotNetFrameWork 4.5 它的偵測方式不是用定時檢查，而是使用Windows的是件觸發，因為定時檢查的間隔可能會造成檢查遺失，就是當檔案進入SRC資料夾後，直到Turnkey排程觸發取走檔案時，如果定時檢查錯過這段時間這時就會檢查不到，而若把定時檢查設定太短，則會削弱大量系統效能(檢查這些資料夾必須使用遞迴處理)，而且檢查時，若檔案此時被Turnkey處理掉，也是會造成偵測漏洞。 使用事件觸發通知好處是非常即時，而且事件被觸發時就會告知目前檔案狀況。因此不會漏掉要接收的資訊。

  說明： 這支程式的用途就是和你的程式擺在一起，然後將這支程式設定成你的程式啟動用。 這支程式啟動時，會依照 INI檔的設定去幫你檢查程式版本。 如果有版本異動時，會提醒使用者要更新程式。 支援： 支援HTTP和FTP協定，可以依照你的需求把更新檔案放在WEB server或是FTP server上 環境： 僅能運行在Windows 下 由 dotNet 4.5 開發，需要作業系統支援 dotNet 4.5 的程式執行， 如果沒有，可以 下載安裝 dotNet FrameWork 4.5 套件 。 下載： LaunchMan 範例： 我有一個 kiosk 程式 main.exe 放在  C:\APP\KioskPatch 桌面上有個程式捷徑連結到 C:\APP\KioskPatch\main.exe 現在，我們把 LaunchMan 程式和這個 Kiosk 程式放在一起 (不放一起其實也可以，這樣比較好管) 修改桌面捷徑改連結到 C:\APP\KioskPatch\LaunchMan.exe 而更新檔案 有兩個 一個是 version.txt ， 另一個為壓縮檔( 例如KioskPatch.ZIP ) 都放在我的網站 www.mycomp.com.tw/Patch/down/ 下 然後在 C:\APP\KioskPatch 下也放一個 version.txt 這兩個 version.txt 內容要不一樣，當內容不同時，才會啟動更新 然後，修改 INI 檔案(範例在下方) [Application] ;使用的背景圖片，自訂圖片，該圖片必須有DPI資訊才能正常顯示 LogoPicture=splash2.png ;淡入效果時間 ;Second unit FadeINDuration=3 FadeOutDuration=1 ;讓背景透明 BackgroundTransparency=true ;顯示訊息文字顏色/位置 MessageTextColor=#0000FF MessageLeftPosition=10 messageTopPosition=130 Title="Kiosk Sell System with .Net" TitleTextColor=#FF0000 TitleLeftPosition=50

  頒獎用顯示程式(含原始碼 pbw) 開發工具：Powerbuilder 10.5 版本：2.0.2.6 版本時間：2019/3/5 平台：Windows 下載位置： https://drive.google.com/file/d/1XX8SDzyeHaZxvOAlmmPOmWu4JJP1dkEp/view?usp=sharing 程式說明： 因應公司於大型會場需要頒獎時，能將得獎者名單顯示在會場投射螢幕上，由於公司參加者眾多超過300人，部分獎項得獎者可能多達50人以上，若主持人連續抽出得獎者並說出得獎者名字或編號時，現場吵雜情況下，得獎者會不知道自己已經得獎，因此透過投射螢幕可以把得獎者清單列於畫面上，讓得獎者不會錯過。

這個是在使用 POI 讀取 EXCEL 的 xlsx 檔案造成的 LOCAL.WorkBook = WorkBookFactory.create(FileStream); 使用 WorkBookFactory.create 時內部會呼叫 POIFSFileSystem.hasPOIFSHeader 函式。  如果呼叫失敗就出現這個錯誤訊息。 所以正常來說 POIFSFileSystem.class 裡面是包含 hasPOIFSHeader 函式的。 看大部分網路上的論壇討論結果或是意見，通常是 POI 所需使用的 jar 檔案使用了不匹配/不同版本的套件導致。 但這個問發現在我另一個 jetty 版的 Railo 4.0.4.001 伺服器上卻不會發生。 為什麼？兩個伺服器版本都是一樣的啊？裡面套件也應該相同的啊？ 為此，我便進行研究了一下。 1、 發生這個錯誤 的伺服器是以 Tomcat7 執行的伺服器，而另一個 不會發生 這個錯誤的是以 jetty 執行的伺服器。而兩方的版本都是當初官方公佈的 4.0.4.001 版本。 2、比對兩邊使用 POI 的 jar 檔案，雙方的檔案尺寸是相同的，檔案數量也相同。     在此處 POI 相關的 jar 共有4個，這些都是同時隨伺服器版本一起發佈的，不是我另外安裝的，應該不會存在版本問題吧。 3、如果 POIFSFileSystem.class 不包含 hasPOIFSHeader 函式，理論上 jetty 伺服器也會出現錯誤。結果卻沒有發生這個錯誤，代表 POIFSFileSystem.class 是正確的。 但，為甚麼？ 所以我用解壓縮軟體來觀察 jar 檔案的成員。 發現了奇怪的的是在 apache-poi.jar 和 apache-poi-tm-extractors.jar 裡面都出現了成員 POIFSFileSystem.class ，而且檔案尺寸完全不一樣！ 而且路徑都在 org.apache.poi.poifs.filesystem 下，我猜這就是貓膩了。 因為在這種情況下只會有一個成員會被載入成功，至於是哪一個先被載入要看伺服器核心的 javaloader 處理規則。 因此，我把這兩個 jar 檔案分別解

一般 CFC 的寫法大概會像上面這樣： 而呼叫方式如下： <cfinvoke component= " COM.extfunc " method= " myescape " returnvariable= " escstr " >     <cfinvokeargument name= " sdata " value= "# myForm.note #" > </cfinvoke> <!--- 返回 escstr ---> <cfoutput> #escstr# </cfoutput> 上面這種方式屬於純 TAG 寫法，寫起來超麻煩，尤其參數很多時就會寫出一堆  <cfinvokeargument>，真是快昏倒了。 其實，也可以使用創建物件方式來使用這個 Component，會方便許多。 我們把上面的 cfc 改成下面方式 <cfcomponent displayname= " extfunc " hint= " 擴充功能 " >       <cffunction name= " Init " access= " public " returntype= " QueryUtility " output= " false "            hint= " Returns an initialized QueryUtility instance. " >           <!--- Return This reference. --->            <cfreturn THIS />       </cffunction>       <cffunction name= "myescape" access= "public" returntype=

最近遇到某些音樂播放器，由其是SONY的車用音響，都出現了這個問題，就是它根本不照我們放置檔案的順序或是其他排序方式(時間)去撥放。而這支程式就是用來重建他的檔案順序用的。 At some Sony music players or car audios,  it read mp3 files order is not follow filename sort or otherwise sort on the USB drive. This program will regenerate file order to the right! 假如我有一個USB隨身碟資料夾，裡面的檔案清單就如下面這張圖： 在 Windows 檔案總管下，看起來就是上面這樣子的，因為檔案總管會預設以檔案名稱來排序，正常得情況我們在 Windows 的播放軟體也會依照這個規則來執行。 然而，目前我在SONY音樂播放器上遇到這個播放順序的問題，它是照下面這種順序去撥放的： 比較前後兩張清單後注意到了嗎？ 第二章的清單順序根本不知道它是依循啥麼的啊？？事實上這就是我在 SONY音樂播放器上遇到的問題。 經過不斷的檢查後發現，原來第二張的檔案順序是在 FAT 表上的出現順序啊!!!!! 這啥鬼？ 原來 SONY 音樂播放器是直接照 FAT 表讀出的檔案順序來播放音樂的，無怪乎我怎麼改檔案名稱，或是檔案時間都沒有用。 要是按照這種方式播放的話，如果要整理檔案，就得把 MP3 檔全部 移出 USB 隨身碟後，再依順序一個一個拷貝(搬移)回 USB 隨身碟。 真是天殺的，如果 USB 隨身碟有滿滿 16 GB音樂檔，那不就搬到天花地老了。這個會死人啊，老兄。SONY，我真服了你們了，東西又不便宜，程式卻寫得這麼爛，真不像 SONY 的產品啊。 索性，自己寫一支程式，專門來做檔案順序『重建』就可以保證在 FAT 上是依照自己訂的順序來跑了。 有興趣的就自己下載看看： 下載檔案/原始碼 這是用 dotNetFramwork 4.5 製作的，所以要執行的話，電腦至少要能支援 dotNetFramwork 4.5 ，或是到 這裡下載 。記得選擇您使用的語系再安裝。 程式載點 (Google drive) 原始碼載點 (Gith

甚麼是WPF WPF(Windows Presentation Foundation) 簡單的說是一種把UI跟程式碼拆開來做的windows應用程式，早期UI的設計與動作都會和程式碼扯上關聯(因為程式碼寫在UI裡面)，導致做美編的人員要動到畫面設計時，還得小心考慮到每個物件裡面的程式碼。而微軟在2006年的.NET Framework 3.0以後，重新去定義Windows APP設計的方向與概念而訂製了 WPF 架構。 我想有在設計android程式的人大概見怪不怪了，畢竟android程式的設計就是如此的，UI跟程式碼本來就是分開在設計的。當然習慣於舊式Coding的程式設計師還是會有點難以適應的，因為它不是『直覺』去設計程式的，而是透過『分析』→『模組化』→『開發設計』這種方式去進行開發的。 雖然WPF也可以用比較傳統方式去開發(把各種程式碼寫在UI的片段下)。 但由於『模組化』才是WPF的精隨 ，所以一開始就栽進 M-V-VM 的環境，對於將來開發會比較有幫助的。 網路上也有不少資料可以參考，我這邊就以我 自己的想法去解釋 ，如一開始的圖片。 Model ： 主要負責資料結構 (Data Model:Data Structure)的建立或與資料庫連結的存取(DAL;Data Access Layer)的各類模組化都是由這一層負責處理。 View ： 主要負責畫面的設計與成型 ，它是一個 .xaml 的 XML 描述檔案，這個描述檔案描述了畫面個元件如何擺放與屬性等，通常它會搭配一個 .cs 的程式碼檔案，雖然可以把程式碼寫在 .cs 裡面，但為了把運算邏輯分離，所以盡可能不要寫入任何與畫面無關的程式碼，甚至根輸入有關的互動運算邏輯也不應該寫在這裡。 ViewModel ： 這個才是View的邏輯核心 ，通常一個View會搭配一個ViewModel，而這個ViewModel負責 View 的資料保存(輸入或是顯示用)與畫面元件的互動或是指令，例如按鈕的行為、輸入資料後的自動動作等等，都是在這個模組去完成。透過 View 與 ViewModel 進行結繫(Biding)的方式，也可以讓 View 接收 ViewModel 傳回來的事件要求。 基本型： 假如我需要一個可以輸入產品名稱、數量、成本 與計算小計的功能。 所