Возник вот какой вопросик. Три программки одновременно работающие на одном компьютере должны сверятся с общими данными и вносить коррективы в данные по мере необходимости. Использование текстового файла очень тормозит. Как выделить участок в памяти для данных для совместного использования???

AllocateMemory, компонент MemPatch, выделяет нужный размер памяти в байтах в любом приложении и выдаёт указатель на выделенную область памяти.
для чтения используется простой ReadProcessMemory в том же компоненте.
для записи использовать WriteProcessMemory.

весь процесс записи чтения, думаю занимает не более 100 мкс

Lora, Используйте компонент SharedStream, с помощью него можно организовать доступ нескольких программ к участку памяти.
Я, лично, использую более простую (легкую в использовании) реализацию - SharedVar от Aziz

Спасибо, мальчики! Всё получилось!!!

nesco, а ведь я тебя предупреждал

[flood]Скажу так - у компонента SharedStream недостаточное, "сухое", неполное описание (ет токмо мое мнение). А эксперименты делать не хотелось, что бы разобраться что да как...[/flood]

Че-то не помню. Ткни, где это было.


А справка с примерами читана была Там есть очень простой пример для обмена между разными копиями одной программы. Это для файловых операций -- там, да, надо понимать, что делать, но примеры-то есть, можно и разобраться

Мне просто было лень, на тот момент, вникать в особенности работы компонента.
[flood]Справка читана!
Не спорю, можно, и разберусь - когда то... А вот SharedVar проще юзать - разбираться почти не надо... [/flood]

Один компонент, ничуть не сложнее другого. Просто патроны разного калибра.
Всё дело в обстоятельствах.
Зачем из пушки палить по воробьям? Но и руками землю рыть не надо, когда есть лопата.

ЩАЗ

Вот чего помню: диспут у нас был. Про то, что проектирование элемента надо начинать с "простоты использования".
Это я так говорил. А ты огорчался и не хотел

В данном конкретном случае - пользователь заказывает "окно" (параметрами Offset и Size) в неком файле.
И ВСЕ -- он получает стрим именно заявленного размера, и байты в этом стриме соответствуют именно заявленному смещению.
А не такому, "какое получится".

Тогда бы "ниасилил" можно было БЫ тупо оставлять без внимания - ну не дано, видимо, это данному пользователю.
А сегодня разве так
Вовсе нет. Вот я таки чего то в этом понимаю... И без пол-литры -- затруднительно было. Да и то - не все понял.
Этим невозможно пользоваться без заглядывания в егонные коды.
Ну вот нафига, спрашивается, мне (как пользователю элемента) врезать в свои алгоритмы расчета смещения и размера (для задания в элемент) еще и знание про гранулярность и размер страницы. Или не до конца понятный Mode...

nesco, ты пойми, логика должна быть повернута в противоположную сторону (т.е. - в правильную, а не так, как у нас).
С негодованием должно отвергаться "докажи что реализация более простого интерфейса возможна"
Но обязательно требовать доказательства, что "реализация более простого интерфейса - невозможна"

Да черт его сейчас знает, может и имело смысл разделить этот элемент на разные части, да и интерфейс построить по-другому, но я его тогда именно так видел, другое на ум не приходило А че ты сам не предложил более простой интерфейс?

Как же не предлагал... Еще как предлагал
А теперь то чего... Обратная совместимость, и прочие "песни о главном"

Я не думаю, что этот компонент очень часто используют. В крайнем случае, ему можно придумать другое имя, а текущий компонент просто скрыть. Последний вариант более предпочтителен, тк таких компонентов у нас далеко не один.

Ну хорошо.
Давай тогда всерьез обсудим вышеозначенную постановку:Грубо говоря, если свойства PageMem и Mode канут в лету -- то будет всем счастье.
Ибо: лучшее средство от перхоти - гильотина


Вот... Разве это не исполнимо

Что-то сложно как то.
Предлагаю такое:
1. Делаем из SharedStream менеджер SharedHeap, убираем все точки и свойства. Пусть он будет иметь свойство "Имя области общей памяти" (которая для удобства будет еще и именем шареного файла) и... (TODO: подумать, что еще может пригодиться. Из кандидатов: максимальный размер выделяемой шареной области. Но пока о концепте). И все.
2. Делаем компонент SharedMemory, который по сути является тем же самым Memory, только со свойством-указателем на менеджера SharedHeap и именем этой шареной переменной.
3. И компонент SharedStream подобный SharedMemory, в котором будет храниться расшаренный поток любых байт (т.к. крайне сложно будет его обыграть через SharedMemory).

Для пользователя все очень просто: кидаем на схему SharedHeap, обзываем и тыкаем сколько хотим SharedMemory.
В плане реализации, конечно, придется попотеть. Но не потому ли интересно программистом быть, чтобы решать такие задачки?