Multicharts 這套交易系統，作為商品即時行情接收 (Quote Manager)、圖表分析與展現 (Charts Window)、指標撰寫 (Power Language)與績效回測 (Portfolio back testing)等功能，都具有相當不錯的穩定/效能與易用性。但唯獨關於部位的資金策略管理 (Positive Feedback Investment Strategies Management)，卻是相當地陽春，使得投資者最好能自行撰寫相關的資金策略部位管理，再與 Multicharts 上述功能模組整合，並實作各券商的自動下單交易協定 (protocol)，如此才比較能建構出較完整全方位的交易系統。
Multicharts 並沒有直接提供外部系統整合的 APIs (Application Programming Interfaces)，這也列為他們家的商業機密吧。若要原廠提供則還需要另行購買，而且據說還相當不便宜。MC 現在唯一能對一般開發者所提供整合的管道是透過 EasyLanguage Extension Software Development Kit (SDK)，也就是在 Power Language Editor 上，透過該 SDK 來呼叫外部 Windows DLL 檔 (C/C++, Delphi, VB ...等實作)，以達成與外部系統整合的手段。
目前看到 (似乎也是唯一？)的作法就是撰寫產出文字檔的 DLL，然後再由交易者自行開發的系統以無窮迴圈的方式一直讀取位於所指定目錄內所產出的各商品檔案。
這也算是一種權衡可解決現狀的妥協方案吧。但我實在很難接受這樣的整合方式，產出文字檔然後以無窮迴圈 (或定時)讀取以處理之．．．。其實我已有見識過某些大戶是以這樣的方式來處理，而且資金規模還頗為龐大。但如果有機會能找出更佳穩定/效能的技術整合方案，我還是把產出文字檔這種方式列為是最不得已的選擇吧。
這兩天從一些相關文件與國內外論壇爬文研究的基本心得，先規劃出 MC 與 客製化交易系統 (主要針對資金部位策略管理模組)的整合架構圖。(其實這應該稱之為實體的分層結構設計規劃)
客製化 (customize)的交易系統，最起碼會分有三個元件 (component)：買賣訊號接收Adapter、資金部位策略管理、自動下單Adapter。
資金部位策略管理是客製化交易系統的核心元件，它需要實作關於資金/部位/風險等相關應用領域的邏輯，但卻非與 MC 直接連結。
自動下單元件Adapter 是需要連至各券商的下單交易系統，所以該模組需宣告定義一個一致性 (universal)的下單介面 (interface)，然後所撰寫連結至所指定券商的下單具體Adapter類別 (concrete adapter)，需實作 (realize)該介面的規格。
至於買賣訊號Adapter，就是接收來自於 MC 所撰寫 Power Language 並呼叫該 DLL (也就是買賣訊號Adapter)的買賣訊號 (主要接收內容包括商品、部位、買/賣、DataTime等資訊)。
上述是架構規劃的巨觀設計思維，至於實作技術的主要難度，當然首要克服的就是買賣訊號Adapter 如何實作並編譯成可被部署 (deploy)的 DLL 元件，並供 MC 來呼叫。
原來是希望能撰寫成 C#.NET 的語法，這樣個人相對熟悉許多。但現實的無奈就是，MC 所能呼叫的 DLL 必須是屬於「UnManaged Code」，也就是傳統的 COM 元件；若要與 C#.NET 元件連結，則還需要再設計 Wrapper 物件，且相關的程序相當繁瑣。 (可參考－Interoperability Overview (C# Programming Guide) )
反正關於技術整合議題，先給一個基本結論：要實作 COM 元件 (且不須註冊 registry)的 DLL，並且未來可以與由 C#.NET 所實作的資金部位策略管理系統，也就是要能有效地連結 UnManaged & Managed Code (.NET CLR, Common Language Runtime)，唯一最佳的實作機制就是 Visual C++。
引用 MSDN－使用 C++ Interop 內的一段說明：
「和其他的 .NET 語言不同，Visual C++ 具有互通性 (Interoperability) 支援，允許 Managed 和 Unmanaged 程式碼存在於相同的應用程式，甚至是同一個檔案中 (須使用 managed、unmanaged Pragma)。 這樣 Visual C++ 程式開發人員就可以將 .NET 功能整合至現有的 Visual C++ 應用程式，不會影響到此應用程式的其他部分。 」
所以不得已，未來幾日也只好勉為其難好好研讀下 Visual C++ 語法，然後試著寫一個小的 Prototype，先能撰寫成供 MC 呼叫的 Unmanaged DLL Code，再透過 Wrapper 呼叫 C#.NET (Managed Code)的應用程式。這個技術管道一旦打通，就比較有機會先實現一個全方位 (包括策略設計、買賣訊號觸發、部位策略管理、自動下單等)的自動化模擬交易系統了。
請問一下
關於 C++ wrapper 的這件事情
由於我本身也不熟悉 C++
因此我請朋友幫我做一個 C++ wrapper 來包 C# DLL
不過 MC一但去call 那個 C++ 的DLL
MC 馬上就會當掉
我嘗試在 C++的 DLL 中不要去呼叫 C# DLL
直接由 c++的DLL回傳值
這樣 MC 是可以正常使用的
如此看來 MC 與這個C++ DLL 的這一條路是通的
我懷疑是呼叫C# DLL 時發生的問題
因此嘗試著用一個獨立的 console 來呼叫 C++ DLL
不過此時 wrapper 是可以正確回傳 C# DLL的內容
綜合以上的測試
1. MC 與 C++ DLL 之間是正常運作
2. C++ 與 C# DLL 之間也是正常運作
唯獨當 MC 呼叫包著 C#DLL 的 C++DLL 會使得MC當掉
不知道您這方面有什麼建議的解決方式 ?
謝謝
其實MC本身也是有提供 RTD Server掛件, 不過我覺得不是很好用
文字檔的輸出還是單純地多, 雖然”感覺”不太好…哈
最近在學習C#+Excel, 但遇到了一些問題, K書中, 有機會再跟你請教~
啊哈，有段時間沒聯絡了。^^
隨時可以 Line 一同研究討論囉~
C# 語法，然後把 Excel 當一整個物件，再從 MSDN 隨時查詢該物件存取的方法，如此就蠻容易掌握如何使用 Excel 了。
年後約個時間喝個咖啡大家一同聊聊吧。 🙂
您好!~可以請問為什麼放棄擴充性似乎比較好的AmiBroker 改用Multicharts 來架構交易系統呢?
另一篇文內有提到的。 就單純是為了報價接收的問題。
另，Multicharts 相對的文件資源比較多喔。
可惜台灣怎麼沒有人要代理 AmiBroker 進來 跟Multicharts 打對台呢
如有冒犯, 尚祈見諒!留言的內容主旨在操作時要跳脫IT思考, 多加點使用者在乎的觀點而已
主因本身也是原IT從業人員, 改專職操作期權已逾8年, 目前在程式交易輔助的部分, 也僅止於半自動化階段; 很多年前便已看過您操作期指的文章, 也不少見您有財富自由的想法, 只是老不見您有人生C型轉彎的實踐動作, 有興趣的話, 歡迎一起多交流想法
yes, 我了解，其實本篇是較當成技術研究心得的，所以也並未提及上述所說的策略/心態等問題。 !^^
個人一直是在軟體/交易這兩個領域的。前者仍佔最大比重、後者其實前幾年交易並不順暢，也的確有您前文所提及的一些心態問題。
如果有機會，您也有空且有意願的話，倒是可以約見請您喝杯咖啡聊聊。 ^^
謝謝您的邀請!
個人原則是網路上僅止於匿名神交, 相信留言討論便可深入溝通了. 我對同為5年級後段班的人特別有好感, 尤其又有類似背景的…
沒有問題的。 🙂
我也是五年級後段班 因為興趣寫程式, 不為無斗米折腰也爬了20年程式碼, 同樣是為了財富自由轉而對交易產生興趣, 我是交易系統 計量策略都自己來, 不用一般人都用的交易工具…人多的地方我就不去 🙂
交易未來懂技術只會是個基本門檻, 財務數學跟演算法才是能不能賺到錢的核心, 跟2000年電子商務改變傳統商務一樣, Fintech其中一個是改變原始金融交易的速度與資訊量, 這是搞技術的另一片天空, 互相勉勵, 有空我會上來跟兩位互相分享.
忘了提一下我的交易經歷, 我主要是做台指option 因為其非線性的訂價特性對小散戶相對有點機會, 資金不太多 但實戰上是有賺點錢, 未來怎麼變成可以養老的事業已經有些規劃, 打算走條慢但腳步穩定可行的路子, 所以, 現在正C型轉彎中 不再只單純寫程式, 也摸清楚交易這檔子事情所有的細節.
一點回首來時路的心得分享給兩位, 要能穩定賺錢其實沒想像中的簡單(也許兩位比我還早體會), 我看過太多有經驗的獨立交易人用這些charting tool 費盡心思 多策略多商品 仍然幾年下來浮浮沉沉掙扎, 當然我也有不少透過自己方式確定穩坐自己一片天的案例, 有幾個關鍵點跟技術不必然有相關, 有些要自己準備好. 有些要實戰才體會
非常歡迎您提供自身的經驗分享。
我想您自身的經歷與心得，足以作為我輩中人諸多參考與學習的。 🙂
全自動化(包括策略設計、買賣訊號觸發、部位策略管理、自動下單…等)很好, 分段完成用[人]來互相連結, 效果也不見得比較差!
盈虧的關鍵在於[切實]執行, 而不在於[順暢]或[快速]執行, 進出策略最重要的是要能適合自己的個性, 因為適性所以才易於執行, 否則客觀上回溯成果很好的策略, 主觀上卻難以執行, 沒用 +100 (不要和我說電腦自動執行沒問題這種話). 因此, 如何能讓最終策略設計成具有 [不得不] 執行的效果(ex: 設計一種心理上沒停損, 而實質上是真停損的機制), 才是花心力的大課題
是的，您這立論是個人原來就是這麼認為的，所以我從來沒有說打造成全自動化的交易系統就一定會獲利或是績效較好。這完全是兩回事。
這篇文章是較站在軟體設計師的角度來看待交易系統的整合與規劃，還有相關技術等議題。其實並沒有涵蓋交易人員應有的策略/紀律/性格等議題的。
也謝謝您補充這些資訊，也讓本文不致讓一般的交易人員誤解。 🙂
P.S. 這個交易系統的規劃另一個重點是站在 “Platform (平台)” 的建置議題。
雖說無限讀檔不是好方法, 但確能解決非OS level的inter-process communication問題. 很多時候對使用者來說, 可行解的時效性比最佳解的完美性重要得多
這倒也非那麼底層的所謂的 “inter-process” 這類的問題，只單純是接口溝通的問題而已。 🙂
yes, 可行性可能來得比最佳解還重要，這個認同的。只不過因有另外的一些整合性的構想，所以文內也有提及，才不得已花些時間研究下 Visual C++ Interoperability 的相關實作問題。
不過，倒是看這些實作文章有時候也別有樂趣的。 ^^
“inter-process”只是一種 類譬喻, 我行文中寫了[非OS level], 不就是沒那麼底層, 而是您所謂的接口溝通的問題 🙂