簡介一款仿照ElementUI TimePicker交互風(fēng)格使用C#與MVVM模式實現(xiàn)的WPF時間選擇器源碼包適合具備WPF基礎(chǔ)、希望豐富桌面端控件庫或?qū)W習(xí)MVVM數(shù)據(jù)綁定的開發(fā)者。資源包含項目完整工程主要文件為C#源代碼415個cs并配有XAML界面定義、生成緩存與編譯輸出dll/exe/pdb等壓縮包總大小918KB共1267個文件可在Visual Studio中直接打開構(gòu)建。內(nèi)容涵蓋從項目創(chuàng)建、視圖設(shè)計、ViewModel封裝、INotifyPropertyChanged屬性通知到時間對話框交互與數(shù)據(jù)綁定的完整實現(xiàn)思路包括通過Slider調(diào)節(jié)小時與分鐘、事件驅(qū)動刷新選中時間的細節(jié)便于對照學(xué)習(xí)完整交互閉環(huán)。當(dāng)前已有420人學(xué)習(xí)下載適合作為WPF自定義控件與ElementUI風(fēng)格遷移的參考樣例。1. 為什么我決定在WPF里手寫一個TimePicker先說結(jié)論Web前端一個好用的組件遷移到桌面端時照搬交互邏輯很容易真正難的是把它翻譯成WPF自己的語言。我之前在做一套基于 .NET 8 的 WPF 上位機項目界面框架用的是 Prism MVVM。系統(tǒng)里有大量的參數(shù)配置界面其中不少字段需要用戶錄入時間。一開始的方案很樸素用 TextBox 讓用戶手動輸入配合字符串校驗。用了一段時間后發(fā)現(xiàn)這樣做的體驗確實不太行——操作人員經(jīng)常輸錯格式上午九點半輸成 21:30 的情況都算好的還有人直接不按HH:mm:ss格式來導(dǎo)致后端解析報錯。后來想過直接用 WPF 自帶的DatePicker但那玩意兒只支持日期不支持時間。又看了看第三方控件庫很多收費的、開源的也都有時間選擇器但為了一個控件引入一套重型UI庫對項目來說代價偏高而且主題風(fēng)格跟現(xiàn)有界面不一定搭。這時候我就想到了ElementUI里的TimePicker。用過 Vue 2 ElementUI 做過后臺管理系統(tǒng)的朋友應(yīng)該都有印象它的交互其實很經(jīng)典一個輸入框點擊后彈出一塊面板里面是小時、分鐘、秒三個獨立滾動的列表滾動到哪個值就選中哪個值。整個交互直觀、確認感強對鼠標操作和觸摸操作都友好特別適合工業(yè)現(xiàn)場那種“點一點、滾一滾”就能完成輸入的場景。我當(dāng)時的想法是與其去找現(xiàn)成的第三方庫不如照著 ElementUI TimePicker 的思路在 WPF 里自己實現(xiàn)一個。一方面可以完全控制交互細節(jié)和樣式另一方面也能把控件封裝成可復(fù)用的組件后續(xù)在別的項目里直接拿過去用。這篇文章就把完整的實現(xiàn)思路、核心代碼和坑記錄下來。內(nèi)容面向的是有 WPF 基礎(chǔ)、熟悉 MVVM、想自己動手做自定義控件的開發(fā)者。如果你只是想要一個能用的時間選擇器這篇文章也能讓你明白這類控件的內(nèi)部機理遇到問題的時候不至于抓瞎。2. 先把交互邏輯拆清楚從ElementUI那里學(xué)到的三件事動手寫代碼之前我把 ElementUI 的 TimePicker 面板反復(fù)用了好幾遍把它的交互拆成了三個關(guān)鍵模塊模塊一輸入框展示狀態(tài)。輸入框本身是一個只讀項點擊區(qū)域任意位置都能彈出選擇面板。面板打開后輸入框里會顯示當(dāng)前選中的時間。ElementUI 的輸入框里還有一個清除圖標在懸浮狀態(tài)下出現(xiàn)點擊即可清空已選時間。這個細節(jié)很小但體驗差異非常大我決定一并實現(xiàn)。模塊二三列滾動選擇器。這是整個控件的核心。小時、分鐘、秒各占一列每列有若干選項選項列表可以自由滾動停在中間高亮位置的值就是當(dāng)前選中值。上下兩端還有漸隱遮罩讓列表看起來有“轉(zhuǎn)輪”的感覺。ElementUI 的寬泛配置里有步進概念比如分鐘可以設(shè)置step 5那么列表就只顯示 0、5、10、15……我最初版本只做到了整分鐘的步進秒的步進留到了后續(xù)擴展。模塊三底部操作區(qū)。ElementUI 默認有“此刻”和“確定”兩個按鈕。點擊“此刻”會立即把時分秒設(shè)為當(dāng)前系統(tǒng)時間點擊“確定”則把面板當(dāng)前選中的時間回填到輸入框。另外還有一個“清空”的鏈接按鈕需要設(shè)置可清空屬性才顯示。操作區(qū)的存在讓用戶對“面板里的臨時選擇”和“真正提交到輸入框的值”有了清晰的心理認知這不是多此一舉而是為了和“隨手滾動一下就把值改了”做區(qū)分。上面對交互邏輯的還原是 Web 端的思路但在 WPF 里實現(xiàn)時有三個關(guān)鍵點需要做技術(shù)映射ElementUIWeb端WPF桌面端技術(shù)要點彈出面板浮層Popup控件Popup天然支持任意位置的浮層展示且能保持焦點管理自主可控滾動選擇列ListBox或ItemsControl ScrollViewer需要處理選中項始終居中、滾動結(jié)束后自動吸附動態(tài)樣式切換DataTriggerControlTemplate通過模板觸發(fā)器實現(xiàn)選項的高亮、激活狀態(tài)響應(yīng)式步進配置屬性依賴用DependencyProperty暴露MinuteStep、SecondStep等屬性在 WPF 里最讓我糾結(jié)的是第二點——滾動列的實現(xiàn)方式。ListBox默認支持鍵盤和鼠標選擇但它默認的選中高亮是隨機的并不固定在中間如果直接把ListBox的SelectedItem綁定到當(dāng)前時間值面板打開時會自動跳到選中項這也是可以利用的。但問題在于ElementUI 那種“滾動到中間即選中”的體驗實際上是需要我們在滾動停止后根據(jù)ScrollViewer.VerticalOffset計算當(dāng)前應(yīng)該選中的那個值再賦值給SelectedItem同時再把該項滾動到列表正中間。這套邏輯用ListBox能做到但要對模板做大量修改把默認的選擇視覺完全覆蓋掉。后來我換了個思路用ItemsControl承載數(shù)據(jù)列表外面套一層ScrollViewer然后用代碼控制選中項滾動到中間。ItemsControl的好處是省掉了ListBox默認那一堆選中視覺我可以完全掌控每一項在不同狀態(tài)下的樣子。3. 控件的整體架構(gòu)與數(shù)據(jù)模型設(shè)計3.1 控件類型選擇自繪超類控件 vs 用戶控件這里需要做一個關(guān)鍵選擇這個 TimePicker 到底從哪個基類繼承方案一是從Control繼承通過ControlTemplate定義控件外觀方案二是從UserControl繼承直接在 XAML 里組合子控件。我的選擇是外殼用UserControl內(nèi)部數(shù)據(jù)邏輯用獨立的TimePickerViewModel。是的你沒有看錯為了快速做出一個穩(wěn)定的版本我先用了偏簡單的方式。因為UserControl的好處很直接我可以在 XAML 里很自然地組合Button、Popup、ListBox不用處理復(fù)雜的模板綁定問題。等這個版本跑順、API 穩(wěn)定之后再去封裝成CustomControl就是水到渠成的事核心邏輯可以復(fù)用。對外暴露的屬性我用依賴屬性實現(xiàn)這樣 MVVM 綁定才可用public static readonly DependencyProperty SelectedTimeProperty DependencyProperty.Register( nameof(SelectedTime), typeof(TimeSpan?), typeof(WpfTimePicker), new FrameworkPropertyMetadata( null, FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, OnSelectedTimeChanged)); public TimeSpan? SelectedTime { get (TimeSpan?)GetValue(SelectedTimeProperty); set SetValue(SelectedTimeProperty, value); } public static readonly DependencyProperty MinuteStepProperty DependencyProperty.Register( nameof(MinuteStep), typeof(int), typeof(WpfTimePicker), new PropertyMetadata(1, OnStepChanged)); public int MinuteStep { get (int)GetValue(MinuteStepProperty); set SetValue(MinuteStepProperty, value); }SelectedTime的類型為什么用TimeSpan?而不是DateTime?因為“時間點”語義和“時間長度”語義在 WPF 里容易混淆。TimePicker 選擇的是“一天里的某個時刻”用TimeSpan表達足夠而且和數(shù)據(jù)庫里的time類型能直接互轉(zhuǎn)。TimeSpan?的可空特性天然支持“未選擇任何值”的狀態(tài)這個對參數(shù)配置界面來說很重要。3.2 面板數(shù)據(jù)源小時、分鐘、秒列表的生成邏輯面板里需要三個列表我直接生成ObservableCollectionint作為數(shù)據(jù)源并為每個集合維護一個當(dāng)前選中索引。這樣ListBox的SelectedIndex綁定推進起來非常直接。這里要注意一個步進邏輯如果MinuteStep 5那么分鐘列表只有 12 項0, 5, 10, ..., 55但一個真實時間比如 3:47它的分鐘部分是 47并不在這個列表里。ElementUI 的處理方式是當(dāng)你滾動某個值之后自動把它向下取整到最近的合法步進值。我做了同樣的處理——在初始化列表時將當(dāng)前值向下取整后再定位索引。小時列表永遠都是 0-23 固定 24 項分鐘和秒列表根據(jù)步進動態(tài)計算private void BuildMinuteList() { MinuteItems.Clear(); int step Math.Max(1, MinuteStep); for (int i 0; i 60; i step) { MinuteItems.Add(i); } }這里有個邊界MinuteStep必須能被 60 整除否則最后一格不完整。我早期沒做這個校驗導(dǎo)致用戶設(shè)置MinuteStep 7時列表漏掉了 56-59選中 55 之后下一次滾動直接跳到 60不存在出現(xiàn)了尷尬的空白。后來我在屬性變更回調(diào)里補上了校驗如果 60 不能整除步進值就把 60 這一項也強行補進去private void OnStepChanged() { // 保證列表完整 if (60 % MinuteStep ! 0) { MinuteItems.Add(60); // 理論上不合法但視覺上至少能滾動 } }說實話這個補丁不算優(yōu)雅但至少不會讓列表出現(xiàn)空白項。更好的做法是在 XAML 使用側(cè)就約束步進值必須是 60 的因數(shù)只是我在代碼里留了兜底。3.3 三列之間的聯(lián)動關(guān)系時分秒三列本身互相獨立但是當(dāng)小時列滾動到最后一項23時分鐘列和秒列不應(yīng)該受影響反之亦然。從時間語義上它們是平級的不存在“小時變了分鐘要清空”的邏輯。但有一個聯(lián)動的隱含邏輯當(dāng)外部SelectedTime變化時三個列表的選中索引需要同步刷新。這個同步邏輯寫在OnSelectedTimeChanged回調(diào)里private static void OnSelectedTimeChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { var picker (WpfTimePicker)d; var newTime e.NewValue as TimeSpan?; picker.internalViewModel.SyncFromTime(newTime); }SyncFromTime會更新當(dāng)前選中索引和輸入框的文本展示。反過來當(dāng)用戶在面板里滾動選擇新值時內(nèi)部 ViewModel 通過事件通知外部更新SelectedTime屬性。注意 MVVM 雙向同步的時候不要死循環(huán)。只要確定“外部 → 內(nèi)部”走的是依賴屬性回調(diào)“內(nèi)部 → 外部”走的是屬性賦值并且在賦值時判斷值是否真的變化就不會出現(xiàn)無限套娃。4. 核心實現(xiàn)彈出面板、滾動吸附、選項高亮4.1 Popup 外殼與焦點管理面板的載體我用Popup這是 WPF 里實現(xiàn)浮層的標準方案。關(guān)鍵配置如下Popup x:NamePART_Popup AllowsTransparencyTrue PlacementBottom PlacementTarget{Binding ElementNameInputBox} StaysOpenFalse IsOpen{Binding IsDropDownOpen, ModeTwoWay} Border BackgroundWhite BorderBrush#DCDFE6 BorderThickness1 CornerRadius4 !-- 面板內(nèi)容 -- /Border /PopupStaysOpenFalse是這里最有意思的配置。它的行為是當(dāng)用戶在 Popup 之外的區(qū)域點擊鼠標時Popup 會自動關(guān)閉。這很符合我們“點擊外部區(qū)域關(guān)閉下拉面板”的預(yù)期。但這里有幾個坑。第一個坑StaysOpenFalse在 Popup 內(nèi)部點擊子控件時如果子控件內(nèi)部有焦點切換比如點擊了 ListBox 的一個項不會關(guān)閉 Popup但如果輸入框本身是只讀的點擊輸入框也不會觸發(fā)失焦。這反而是個好現(xiàn)象。第二個坑如果在 Popup 內(nèi)部放了另一個可輸入文本的控件點擊它可能沒問題但鍵盤 Tab 切換焦點時Popup 會意外關(guān)閉。所以面板內(nèi)的可交互控件盡量用Button、ListBox這類不要放TextBox。4.2 列表吸附居中的實現(xiàn)細節(jié)吸附居中是整個控件里最容易做飄的部分。我最初直接把ListBox的ScrollIntoView用來居中結(jié)果發(fā)現(xiàn)ScrollIntoView只是確保項可見不是確保居中。實現(xiàn)真正的居中需要自己算偏移量。思路是每一項高度固定設(shè)為 36px那么滾動到第 N 項時讓該項出現(xiàn)在列表正中間需要把ScrollViewer.VerticalOffset設(shè)置為// 面板可視區(qū)高度為 PanelViewportHeight項高度為 ItemHeight double targetOffset n * ItemHeight - (PanelViewportHeight - ItemHeight) / 2.0;比如面板高度是 180項高 36一個面板里能顯示 5 項。要讓索引為 3 的項居中偏移量就是3*36 - (180-36)/2 108 - 72 36。也就是說第 3 項在滾動 36 像素后剛好位于可視區(qū)中間。滾動結(jié)束后還需要計算當(dāng)前居中項。我監(jiān)聽ScrollViewer的ScrollChanged事件private void OnScrollChanged(object sender, ScrollChangedEventArgs e) { if (e.VerticalChange 0) return; var scrollViewer (ScrollViewer)sender; double offset scrollViewer.VerticalOffset; int centeredIndex (int)Math.Round( (offset (scrollViewer.ViewportHeight - ItemHeight) / 2.0) / ItemHeight); centeredIndex Math.Max(0, Math.Min(centeredIndex, ItemsCount - 1)); if (centeredIndex ! _currentCenteredIndex) { _currentCenteredIndex centeredIndex; OnCenteredIndexChanged(centeredIndex); } }這段代碼看似簡單但有一個使用體驗上的問題如果用戶滾動到兩個選項的交接處比如偏移量 37 或 35四舍五入后索引不會立刻變化會有一種“卡在中縫”的感覺。ElementUI 的處理是滾動停止后會自動彈性吸附到最近的項。要實現(xiàn)這種效果需要監(jiān)聽?wèi)T性滾動結(jié)束。WPF 的ScrollViewer在鼠標滾輪操作后有慣性嗎默認沒有鼠標滾輪是離散的格滾動。觸摸板則會有慣性慣性結(jié)束后ScrollChanged事件會觸發(fā)一輪VerticalOffset的微小變化但不會自動吸附。我采取的方案是在ScrollChanged事件里加了一個DispatcherTimer延遲判斷。如果 80 毫秒內(nèi)沒有新的滾動事件就認為滾動結(jié)束執(zhí)行一次平滑吸附動畫private void RestartScrollTimer() { _scrollTimer.Stop(); _scrollTimer.Start(); } private void OnScrollTimerTick(object? sender, EventArgs e) { _scrollTimer.Stop(); SmoothScrollToIndex(_currentCenteredIndex); }平滑滾動用ScrollViewer.ScrollToVerticalOffset搭配一個DoubleAnimation動畫動畫時長控制在 120ms 左右手感比較接近 Web 端的轉(zhuǎn)輪效果。4.3 選項模板與高亮觸發(fā)的實現(xiàn)每個選項的數(shù)據(jù)模型很簡單public class TimeItem { public int Value { get; set; } public string DisplayText Value.ToString(00); }列表項的樣式用ControlTemplate定義核心是“居中高亮”效果ListBox.ItemTemplate DataTemplate Grid Height36 TextBlock Text{Binding DisplayText} HorizontalAlignmentCenter VerticalAlignmentCenter FontSize18 Foreground#606266/ /Grid /DataTemplate /ListBox.ItemTemplate但“高亮”不能只靠ListBox.SelectedItem來實現(xiàn)因為滾動過程中選中項始終在變化默認的選中背景是方形的不好看。我在列表上方疊加了一層半透明的“高亮指示條”固定在中間位置模擬輪盤的選中槽。這樣滾動列表時視覺上就是一條高亮條在中間而各項從它下方劃過。這個方案比逐項改ItemContainerStyle的IsSelected觸發(fā)要簡單很多而且視覺上穩(wěn)定。如果再配上上下漸隱遮罩就很有 ElementUI 那種“滾輪”味道了。高亮指示條的 XAML 大概是Grid ScrollViewer x:NamePART_HourScroll .../ !-- 中間高亮條 -- Border Height36 VerticalAlignmentCenter Background#F2F6FC BorderBrush#E4E7ED BorderThickness0,1,0,1 IsHitTestVisibleFalse/ !-- 上下漸隱遮罩 -- LinearGradientBrush ... ... /LinearGradientBrush /Grid這里IsHitTestVisibleFalse特別重要。如果不設(shè)置遮罩和高亮條會攔截鼠標點擊導(dǎo)致ScrollViewer收不到鼠標滾輪事件。我第一次實現(xiàn)時就忘了結(jié)果鼠標滾輪在列表中間滾動無效只能在邊緣滾動排查了好一陣才發(fā)現(xiàn)是這層透明層在“吃”鼠標事件。4.4 確定、此刻、清空按鈕的實現(xiàn)底部操作區(qū)在 Popup 內(nèi)部邏輯相對獨立“此刻”按鈕設(shè)置當(dāng)前系統(tǒng)時間到三個列表并同步SelectedTime。不關(guān)閉 Popup方便用戶確認后再點確定?！按_定”按鈕把當(dāng)前列表選中值寫入SelectedTime關(guān)閉 Popup?！扒蹇铡卑粹o把SelectedTime設(shè)為null關(guān)閉 Popup。按鈕命令用ICommand實現(xiàn)。我在 ViewModel 里定義了三個命令ConfirmCommand、NowCommand、ClearCommand。這里比較考驗 MVVM 設(shè)計的是ConfirmCommand需要讀取的是“面板當(dāng)前的臨時選中值”而不是SelectedTime屬性因為用戶可能改了列表但沒確定。所以 ViewModel 內(nèi)部維護了一個TempHour、TempMinute、TempSecond的臨時值只有點“確定”才把這些臨時值合并進SelectedTime。private void OnConfirm() { var time new TimeSpan(TempHour, TempMinute, TempSecond); if (SelectedTime ! time) SelectedTime time; IsDropDownOpen false; }還有一個小細節(jié)當(dāng)用戶通過輸入框手動輸入時間并回車后輸入框的值也要回填到SelectedTime。由于輸入框綁定的是文本字符串我需要在 ViewModel 里先把字符串解析成TimeSpan解析失敗就恢復(fù)原文本。這個邏輯放在一個TextInputCommand里通過KeyDown事件觸發(fā)比LostFocus觸發(fā)更可控。5. 與 MVVM 集成的綁定細節(jié)與可復(fù)用性改造5.1 依賴屬性的綁定鏈設(shè)計整個控件對外暴露的核心屬性其實只有三個屬性名類型說明SelectedTimeTimeSpan?選中的時間雙向綁定MinuteStepint分鐘步進默認 1SecondStepint秒步進默認 1IsDropDownOpenbool面板展開狀態(tài)必要時外部控制IsDropDownOpen也做成了依賴屬性方便在某些頁面實現(xiàn)“點一個按鈕自動彈出時間選擇器”。這個屬性在內(nèi)部綁定到Popup.IsOpen。綁定鏈非常關(guān)鍵的一點是依賴屬性變更必須通知內(nèi)部 ViewModel而內(nèi)部 ViewModel 的變更要能反映到依賴屬性。我用ViewModel的PropertyChanged事件來更新而不是直接在回調(diào)里賦值這樣不會嵌套觸發(fā)private void OnSelectedTimeChanged() { // 外部綁定的值變化了 - 更新內(nèi)部UI狀態(tài) SyncFromTime(SelectedTime); }在SyncFromTime里做一次值比較只有TimeSpan真正不同才更新界面上三個列表的SelectedIndex。這樣可以避免SelectedIndex變化又回引發(fā)SelectedTime賦值構(gòu)成死循環(huán)。5.2 在 Prism 項目中的實際使用范例在 Prism 的 ViewModel 里使用這個控件無非就是正常綁定private TimeSpan? _startTime new TimeSpan(8, 30, 0); public TimeSpan? StartTime { get _startTime; set SetProperty(ref _startTime, value); }XAML 里controls:WpfTimePicker SelectedTime{Binding StartTime, UpdateSourceTriggerPropertyChanged} MinuteStep5 /這里有一個我在項目中實際踩過的坑如果SelectedTime用ModeTwoWay綁定且UpdateSourceTriggerPropertyChanged那么每次面板內(nèi)列表滾動變化都會更新源屬性。這在 Prism 的SetProperty里會觸發(fā)大量通知如果源屬性還關(guān)聯(lián)了后端保存邏輯比如PropertyChanged里自動調(diào)用數(shù)據(jù)庫保存性能就會出問題。解決辦法有兩個綁定用默認的LostFocus更新方式只在失焦時更新源在 ViewModel 層做節(jié)流比如使用 Rx 的Throttle操作符。我最終采用的是方案一UpdateSourceTriggerLostFocus。用戶點擊“確定”關(guān)閉面板后焦點回到輸入框此時才觸發(fā)源屬性更新。對于配置界面來說這個行為更自然。5.3 控件主題與樣式的可擴展設(shè)計為了讓控件融入不同項目的視覺風(fēng)格我把所有顏色、尺寸、圓角都抽成了靜態(tài)資源而不是寫死在模板里SolidColorBrush x:KeyTimePickerPopupBackgroundBrush Color#FFFFFF/ SolidColorBrush x:KeyTimePickerItemHighlightBrush Color#F2F6FC/ System:Double x:KeyTimePickerItemHeight36/System:Double這樣外部項目可以隨時覆蓋這些資源來調(diào)整風(fēng)格。另外輸入框外框我直接復(fù)用了 TextBox 默認樣式?jīng)]有額外重寫這樣可以保持項目內(nèi)輸入框一致性。6. 實戰(zhàn)中遇到的5個坑與排查過程6.1 Popup 點擊外部關(guān)閉后輸入框顯示文本沒刷新這個問題的現(xiàn)象是彈出面板滾動到一個新值不點確定直接點擊外部關(guān)閉下拉框。結(jié)果輸入框顯示的還是舊值。原因很明確我沒有在IsDropDownOpen從 true 變?yōu)?false 時做回滾處理。ElementUI 的行為也是這樣的面板的臨時值不點確定不會提交。所以這個其實是符合預(yù)期的。但用戶不這么想他們第一次操作時很容易誤以為值已經(jīng)改了。我后來加了一個輔助提示捕獲面板關(guān)閉事件如果當(dāng)前臨時值和提交值不一致在輸入框背景上給一個淡黃色標記提示“有未提交的變更”。后來覺得這個提示太“像編輯器”了而且增加了很多復(fù)雜度最終還是通過行為設(shè)計解決——用戶點確定才提交點外部關(guān)閉就恢復(fù)顯示舊值。6.2 ListBox 的虛擬化導(dǎo)致的居中計算偏差當(dāng)列表項數(shù)量較大比如秒列表 60 項時ListBox默認會啟用虛擬化。這會導(dǎo)致一個現(xiàn)象在滾動事件里訪問某個ListBoxItem的TransformToAncestor坐標時該項可能尚未生成返回的坐標是 0。解決方案關(guān)閉虛擬化。VirtualizingStackPanel.IsVirtualizingFalse/VirtualizingStackPanel.IsVirtualizing代價是列表項全部加載內(nèi)存占用會大一點。但由于每個時間選擇器的列表只有 60 項最多 241212 個項完全在可接受范圍。這個坑讓我認識到列表小的時候虛擬化帶來的好處遠小于它引入的坐標計算復(fù)雜度。6.3 高 DPI 屏幕上的像素偏移在 4K 高分屏上WPF 的坐標計算和縮放必須考慮 DPI。ItemHeight 36是設(shè)備無關(guān)單元DIP但在某些縮放比例125%、150%下實際渲染時的像素網(wǎng)格可能不是整數(shù)導(dǎo)致滾動吸附后高亮條邊界出現(xiàn)半像素模糊。解決方式在控件加載時獲取當(dāng)前的 DPI 比例把偏移量計算對齊到像素網(wǎng)格var presentationSource PresentationSource.FromVisual(this); if (presentationSource ! null) { double dpiX presentationSource.CompositionTarget.TransformToDevice.M11; pixelAdjustedOffset Math.Round(offset * dpiX) / dpiX; }這個寫法在 125% 縮放下能把模糊問題壓到最小。并不完美但實際視覺上基本可接受。6.4 ScrollViewer 的 CanContentScroll 必須設(shè)為 True這是我踩過的最隱蔽的一個坑。ScrollViewer默認CanContentScrollTrue但如果ItemsControl內(nèi)部嵌套了別的控件可能被隱式改成False。一旦CanContentScrollFalseScrollViewer滾動的是物理像素而不是“項”的單位導(dǎo)致ScrollChanged里按ItemHeight去推索引時計算結(jié)果完全不可用。排查過程比較曲折我一度以為是 DPI 問題后來在即時窗口里輸出VerticalOffset的連續(xù)變化值發(fā)現(xiàn)每次滾動的步長不是 36 的倍數(shù)才意識到是CanContentScroll的問題。強制設(shè)為True后VerticalOffset就按項來跳變了計算也就穩(wěn)了。6.5 鍵盤方向鍵操作被滾動條攔截在ListBox默認行為中鍵盤上下方向鍵可以移動選中項。但在我們這個“滾動即改值”的自定義列表里方向鍵操作會讓用戶覺得列表選中項在高亮條之間移動但高亮條不動體驗很割裂。所以我在滾動列的PreviewKeyDown事件里攔截了方向鍵改為直接滾動列表內(nèi)容if (e.Key Key.Up || e.Key Key.Down) { e.Handled true; int offset e.Key Key.Up ? -1 : 1; SmoothScrollToIndex(_currentCenteredIndex offset); }這樣鍵盤操作和鼠標滾輪的操作邏輯統(tǒng)一了都在“改變居中項”。7. 體驗優(yōu)化與后續(xù)擴展方向7.1 輸入框直接輸入的兼容只依賴滾動選擇還是不夠效率。用戶有時知道自己要輸入“9:30”沒有必要打開面板一路滾下去。所以我為輸入框加了HH:mm:ss的文本解析支持允許用戶直接輸入。輸入框綁定一個字符串屬性失焦或按回車時解析解析成功后同步SelectedTime失敗則還原。這里我參考了 ElementUI 對輸入可讀格式的處理允許HH:mm、HH:mm:ss兩種格式冒號是半角前后空格忽略。解析用TimeSpan.TryParseExact兩次嘗試即可if (TimeSpan.TryParseExact(text, hh\\:mm, null, out var result) || TimeSpan.TryParseExact(text, hh\\:mm\\:ss, null, out result)) { SelectedTime result; }有一點要注意hh會被理解為 12 小時制HH才是 24 小時制。WPF 的TimeSpan解析里沒有 12/24 小時制的概念直接表示“小時數(shù)”。我之前曾用DateTime.TryParseExact來解析結(jié)果發(fā)現(xiàn)25:00也能被解析成第二天的 1:00這肯定不符合時間選擇器的預(yù)期所以換回了TimeSpan.TryParseExact它能正確拒絕大于 24 的值。7.2 禁用狀態(tài)與只讀模式參數(shù)配置界面常有“當(dāng)前步驟不可編輯”的狀態(tài)所以控件必須支持IsEnabledFalse并且禁用時要保持輸入框文本可見。WPF 的UserControl默認繼承IsEnabled傳遞但下拉按鈕和 Popup 的打開邏輯要主動檢查private void OnOpenButtonClick(object sender, RoutedEventArgs e) { if (!IsEnabled) return; IsDropDownOpen true; }這里有一個小坑IsEnabledFalse狀態(tài)下點擊輸入框依然會觸發(fā)MouseLeftButtonUp事件只讀模式下輸入框不會聚焦但事件仍會冒泡。所以輸入框的打開事件也要主動檢查IsEnabled否則會出現(xiàn)“禁用了還能點開彈窗”的奇怪行為。7.3 可能的擴展范圍選擇、跟隨時鐘變化、觸摸支持后續(xù)如果項目需要我可以在這個控件基礎(chǔ)上繼續(xù)擴展開始-結(jié)束時間范圍給控件增加一個ModeRange內(nèi)部維護兩個TimeSpan?值面板里用兩個高亮條分別選擇實現(xiàn)對“班次時間段”這種配置的快速錄入。系統(tǒng)時間跟隨面板底部加一個“當(dāng)前時間”數(shù)字每秒刷新點擊即填入。適合需要輸入“當(dāng)前精確時間”的場景。觸摸支持工業(yè)場景有很多觸摸屏機器。當(dāng)前實現(xiàn)里列表滾動依賴鼠標滾輪和方向鍵觸摸屏上體驗一般。需要額外處理ManipulationDelta事件實現(xiàn)慣性滑動。這個改造成本不低等到真有需求時再做。快捷選項類似“上班時間 08:30”“午休結(jié)束 13:00”這類固定時段可以直接在面板頂部放幾個快捷鍵按鈕用戶點擊即選中。不過以上這些都是錦上添花。核心控件跑穩(wěn)了后續(xù)加需求就是往 ViewModel 里塞邏輯的事架構(gòu)不會變。8. 最后分享一點個人的實現(xiàn)心得這個仿 ElementUI 的 WPF 時間選擇器從前到后大約花了我三個晚上的業(yè)余時間。第一版是很粗糙的沒有鍵盤操作、沒有輸入框解析、沒有 DPI 適配滾動吸附也經(jīng)常飄。真正讓它變可靠的是后面幾輪現(xiàn)場使用反饋操作員說“滾完了想按回車卻沒反應(yīng)”我加了鍵盤事件有人說“想直接輸 9:30 不想滾”我加了文本解析還有人說“觸摸屏上滾不動”這個我目前還沒完全解決但已經(jīng)知道了方向。如果你也要做類似的自定義控件我最大的建議是先仔細還原 Web 端/成熟產(chǎn)品的交互細節(jié)把每一步用戶操作都列出來然后再考慮技術(shù)實現(xiàn)。技術(shù)選型都簡單難的是對交互細節(jié)的理解和堅持。很多控件做出功能但是難用就是因為實現(xiàn)者根本沒有想過“點外部關(guān)閉時臨時值怎么辦”這類細節(jié)。代碼好不好看不重要用戶用著順手才是第一原則。這個控件目前的代碼量不算大核心邏輯幾百行就夠。后續(xù)我會考慮把控件模板進一步改造為標準CustomControl的形式讓使用方不繼承我的 ViewModel 也能用。如果你做過類似的控件歡迎交流你的實現(xiàn)思路和踩坑經(jīng)驗。本文還有配套的精品資源點擊獲取