View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003836 | Wishes | Plugins API.Dialog | public | 2021-01-02 18:08 | 2021-01-05 07:31 |
Reporter | Xer0X | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 3.0 | ||||
Summary | 0003836: Implement DialogEvent DM_GETDLGITEMSHORT, as shorter version of DM_GETDLGITEM | ||||
Description | Described here, but still is not implemented: https://api.farmanager.com/ru/dialogapi/dmsg/dm_getdlgitemshort.html Discussion is here: https://forum.farmanager.com/viewtopic.php?f=57&t=11966 usage case was described as follows: На большие элементы-списки, например историю, DM_GETDLGITEM берет по 20 милисекунд, на все остальные обычные элементы - ноль миллисекунд. имело бы смысл получать урезанный вариант элементов без списков, если они не нужны .. надо читать все элементы у всех диалогов для некоего анализа, исходные данные такие: * незагруженный (10% нагрузки) процессор со средним CPU в 10% Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz, 2301 Mhz, 2 Core(s), 4 Logical Processor(s) Installed Physical Memory (RAM) 12.0 GB * история из 30,000 записей .. В среднем, повторно запуская чтобы были "горячие" запуски, получаем в среднем 80 милисекунд, что весьма ощутимо, тем более что в историю приходится лазить очень часто.. .. на всякий случай отмечу что, что 30,000 это не количество элементов диалога, а количество значений в списке, которые как раз и не нужны, но идут в нагрузку к запросу на элемент, который нужен, но без этого его списка. | ||||
Steps To Reproduce | local F = far.Flags local G = far.Guids local tbl_dlg_menu_hist_guid = { [G.HistoryCmdId] = true, [G.HistoryEditViewId] = true, [G.HistoryFolderId] = true } Event { description = "Test DM_GETDLGITEM(SHORT) for \"historical\" menus"; group = "DialogEvent"; condition = function(evt, fde) -- we interested only in single open event: if evt ~= F.DE_DLGPROCEND or fde.Msg ~= F.DN_GOTFOCUS then return end -- dialog info should be ready to read it: local dlg_info = far.SendDlgMessage(fde.hDlg, F.DM_GETDIALOGINFO) if not dlg_info then return end -- normalize binary GUID representation to readable string: local dlg_guid = string.upper(win.Uuid(dlg_info.Id)) -- GUIDs of interest only: return tbl_dlg_menu_hist_guid[dlg_guid] end; action = function(evt, fde) -- lets put time measure base point: local t_dlg_elm_get_1 = Far.UpTime -- fetch the menu item SINGLE element: local dlg_elem = fde.hDlg:send( -- currently the only flag message to get it: "DM_GETDLGITEM", -- this was not implemented: -- "DM_GETDLGITEMSHORT", -- number of the menu list element in the dialog structure: 1) local t_dlg_elm_get_2 = Far.UpTime -- so, the time is: (average is 80 ms on decent hosts) local t_dlg_elm_get = t_dlg_elm_get_2 - t_dlg_elm_get_1 -- this is the ELEMENT list of VALUES: local tbl_hist_list = dlg_elem[6] -- put this small report here: (catch it with DbgView of SysInternals, for example) win.OutputDebugString(string.format("FAR: time to get dialog elem: %s, which has %s history items", t_dlg_elm_get, #tbl_hist_list)) end; } | ||||
Tags | No tags attached. | ||||
Build | |||||
|
What is meant to be, just quick zero-time fetch of the dialog element without ANY of it's potentially huge lists. because those lists can be really huge, and for API at will take significant time to allocate memory, and will take away memory space as well, and in many cases it is totally unnecessary. In the given example the dialog control list at position 6 posses list of historical items countin 30,000. Lets suppose we want not or cannot clean the history, history is very likely important to keep. |
|
Есть такая замечательная функция Dlg.GetVlue(Pos, Type). Просто хотелось бы расширить функционал этой функции. Для конкретно Вашего примера хотелось бы получать значение 6-го элемента (истории). А для универсальности и эффективности - добавить возможность получить значение любого элемента итема (например, в качестве Type указывать -№, где № - номер элемента. Ну, или добавить Type и ещё один параметр (просто я не знаю, как проще) |
|
@buniak_a_h Здесь это оффтопик. Создайте отдельный тикет. |