Delphi Динамический Dll - глобальная переменная
простая строка JavaScript для плавания
var it_price = chief_double($("#ContentPlaceHolder1_txt_it_price").val());
function chief_double(num){
var n = parseFloat(num);
if (isNaN(n)) {
return "0";
}
else {
return parseFloat(num);
}
}
8 ответов
Думаю, у вас есть 2 основных варианта.
предлагают 2 версии вашей функции, ту, что у вас есть сейчас, плюс другую, в которой они передаются в буфер (запись, что угодно), из которого вы можете прочитать предыдущее состояние, и конечно обновить состояние в. Назовите это высокопроизводительной версией функции. Они захотят его использовать.
Сохраните состояние, как если бы вы использовали файл cookie (по сути, это то, что он есть) где-нибудь в файле.
Вариант 1 потребует модификации приложения хоста, но будет привлекательным для хоста разработчики приложений, вариант 2 не потребует изменений в главном приложении, но не будет таким производительным.
Я лично не склонен начинать возиться со счетчиком ссылок, предположительно хост-приложение выгружается для причина, если бы я был разработчиком основного приложения, это бы меня раздражало.
Предупреждение, грязный взлом:
Вы можете загрузить себя.
Каждый вызов LoadLibrary увеличивает счетчик ссылок, FreeLibrary уменьшает его . Только если счетчик достигает нуля, DLL выгружается.
Итак, если ваша DLL загружается в первый раз, вы просто загружаете свою библиотеку снова, увеличивая тем самым счетчик ссылок. Если вызывающее приложение вызывает FreeLibrary , счетчик ссылок уменьшается, но DLL не выгружается.
EDIT: Как указал mghi, DLL будет выгружена, если процесс завершится, равен ли счетчик ссылок нулю.
Another solution, if you have a large amount of global data to share, would be to create a windows service to "cache" the state data. You would also need to implement some sort of IPC that works across the process boundary, such as memory mapped files, mailboxes, COM (single instance for this case), TCP/IP ect. You may find that this overhead would be more than just writing the state to a file, which is why I would only recommend this approach if the amount of state data is excessive, or will only be dealt with in parts of the whole for each request into your dll.
For the COM approach, the service doesn't have to do much other than request (and hold onto) an instance of the com object you will be using to maintain state. Since it is a single instance com object, all requests will be to the same instance, thus allowing you to save your state between requests. Requests to the object are serialized, so this could be a performance issue if you have multiple clients requesting data on the same machine at the same time.
Лучший способ - использовать класс, содержащий «глобальные переменные». Вы создаете экземпляр объекта и передаете его в качестве параметра функциям dll. Но это вам не поможет, потому что вы не можете изменить вызывающее приложение.
Если вам нужно сохранить глобальные данные в dll, решение состоит в том, чтобы записать их в файл. Но это серьезно сказывается на производительности.
На вашем месте я бы сохранил значения этих глобальных переменных в файле при освобождении библиотеки DLL и загружал их при инициализации. У меня так нет причин сохранять дамп памяти dll на диск.
Записывать значения в реестр при освобождении библиотеки DLL и читать значения из реестра при загрузке библиотеки DLL. Не забудьте указать значение по умолчанию, когда при чтении обнаруживается, что ключ не был установлен.
-Al.
Я согласен с предыдущими комментариями об опасности глобальной информации о состоянии, хотя могу представить, что она может понадобиться.
Я предлагаю более чистую версию грязного взлома DR, в которой нет обратная сторона постоянства, как ответ Скамрадта:
Очень маленькое приложение:
Оно вообще не имеет внешнего вида, оно не отображается на панели задач.
Задача № 1: Загрузить DLL
Задача № 2 : Возьмите командную строку, запустите ее и дождитесь ее завершения.
Задача № 3: Выгрузить DLL
Задача № 4: Выход.
Программа установки:
Находит ярлык (-ы) в основное приложение и изменяет их так, чтобы небольшое приложение работало, исходное местоположение, на которое указывает ярлык, становится первым параметром.
Результаты:DLL остается в памяти только до тех пор, пока работает основное приложение, но не выгружается каждый раз, когда программа выгружает ее.
This may also be helpful
option 1:
Create a shared memory area that holds your variables backed by paging file - if you're able to open that shared memory area, your dll was previously loaded (assuming "private" shared memory name, maybe named something like process_id_yourdllname) - if you can't open it, then you create and initialize it the first time. If you create it, then you don't bother deleting it - but if you open it, you would close it - when unloading. I believe the area will be released when the application closes, as no other applications should have handles to this particular "private" shared memory area.
option 2:
Create a second .dll that exists just for the purpose of managing your global variables. Your dll A can load that dll B, and not free it, placing in dll B whatever you need to manage the global variables. It should go away when the application goes away, and I don't think you probably need to care about the (presumably useless) reference counting involved (since you wouldn't be unloading dll B).