В паскале и в Дельфи приходится работать с файлами, которые имеют тип record, хотелось их обработать явно с помощью компонет HIASM-а, но такого нет!

Да согласен записей у нас нет.
А хотелось бы.

это не совсем так... В терминологии HiAsm запись представленна МТ потоком с заменой имен на однозначный порядок следования элементов. Всвязи с чем не понятно чего именно хотелось бы и для чего... Без самостоятельного же разбора этого предложения и освещения его реализации в рамках среды дальше "А хотелось бы" дело не сдвинется никогда.

Хотелось бы создавать файлы с произвольным доступом к каждому элементу записи.
То есть один файл с разнотипными данными.
Доступ к данным по имени.
Вообщем программа создаёт такой файл сама,и сама его обслуживает, а я задаю только структуру.
Реализацию вижу как создание группы компонентов.
1)Создание структуры записи.
2)Записьчтение
3)Поиск
МТ-сам файл не создаёт!

то, что описано выше называется База Данных. Если слова "БД" и "файл" стоят рядом, то такое уже называется SQLite. Т.е. полезность по прежнему не раскрыта.

В идеале да, это -- база данных, хотя, record в Delphi больше похож на стрим, который записывает фиксированную структуру. Так что, кто хочет иметь record, юзайте стрим. Но мое мнение -- нафиг оно надо, когда есть SQLite.

сделать еще какой-нибудь MTtoStream конвертор с некотором форматом описания типов полей и больше ничего не нужно будет

Кстати, была такая идея. Я там застрял только с записью динамически изменяемой структуры типа Bmp, Ico и тд. Но сделать можно.

nesco, Bmp, Ico никогда и никто в сериализуемые структуры не включает. Классическое представление типа record это набор из полей типа Int, Char*(строка фиксированной длинны), Float. Любые данные, не вписывающие в эти типы сохраняются как char*. Пример структуры:
т.е. имеем МТ из 6 элементов - строка, целое число, строка, строка, действительное число, строка. При этом поле foto может содержать данные в каком угодно формате - BMP, JPEG, PNG, ICO... Очевидно конвертору необходимо в неком виде предоставлять информацию о типах, чтобы это все работало корректно.

Вот в этом посте есть примеры "классического" представления данных в файлах
Там же есть примеры напрягов (пример сделан давно, элемент DataToFileEx я еще тогда не сотворил) для прочитать эти классические форматы

Хотя постановка поста мне больше напоминает такую: Дяденька, сделайте это за меня, потому-что мне за это и думать не охота
Тоже самое могу отнести к предложениям за MathParse

Для решения этой же задачи "без напрягов" мне достаточно элемента DataToFileEx.
А само решение - это просто работа, которую нормальные люди выполняют ежедневно, и считают это вполне нормальным
А MT там, или еще что....
Наверное потому, что не имею привычки пугать народ своими познаниями умных слов - была задача, и я ее просто решил.
Про "напряги" запомнил - элемент сделал на будущее.
Все.
Вот и вся проблема.

Да имено так. У меня есть результаты экспериментов сохранненных в file of record. а дальше подобные поля, правда там массивы большие.
Я их обрабываю в дельфи, а уже не с руки, т.к. в HIASM приятней, все-таки я электронщик и мне уютней работать со схемами!

Ну незнаю как на счёт полезности.
Но например мне проще написать recod
чем делать это в SQLite(вообще то я так и сделал).
Это профессиональные программисты пускай изучают
по 10 языков.
А простым смертным и одного хватит.(это хобби)

Вообщем я думаю что основная масса здесь именно поэтому.

А моё мнение нафиг ненадо мне SQLite для БД в 100 CD дисков ,100 клиентов и так далее.
Много ты тут видел народу которые знают по несколько языков.
Или услышав слово SQLite тут же побежали его изучать.
К тому же если такой файл уже существует(созданный в Делфи на основе record)
На HiAsm создать к нему оболочку гораздо проще.
По сути HiAsm это и есть визуальная оболочка к языкам программирования.
SQL это отстой 60х.(текстовое программирование)
Вот как раз Hiasm и ему подобные являются оболочками
к этому отстою.
И если на HiAsm можно будет создавать оболочки ко всевозможным БД(уже существующим)
Это только только прибавит ему вес в мире программированиия.
Попробуй сделать оболочку к файлам БД 1С бухгалтерия,торговля и склад.
Заточенную под определённую задачу - у тебя её с руками оторвут.

---

Я тут вдруг подумал а может Hiasmy как раз и нужны подобные
пакеты (работа с уже существующими БД).
Это и прибавит популярности и позволит обратить на себя внимание
профессиональных программистов.
Хай завидуют скорости и удобству разработки.

Вячеслав, нужен не отдельный пакет, а набор компонентов а-ля FTCG для быстрого построения простых SQL-запросов. Пока идея такая: сделать контейнер, подобный контейнеру для FTCG в Delphi, плюс компоненты для него (Select, Insert, Update, Delete), плюс (возможно) более "крутые" - CREATE TABLE, DROP TABLE, ADD COLUMN и т.п.

А не будет например создание пакета для баз 1С нарушением авторских прав?

Вячеслав, ни в коем разе не согласен со словами "программисты", "10 языков" и со всеми остальными тоже. Это аргументация школьника, которому лень учить новую теорему - эта теорема не сложнее и не проще всех предыдущих, она просто новая. HiAsm не требует знания языков - но от знания форматов он к сожалению никого не освобождал и если уж мы решили причислить к языкам вообще все, что вводится с клавиатуры, то мне не понятно, почему за язык не принимается формат INI, почему ввод тегов bbcode на форуме не считается языком, почему XML в эту же категорию не попал или, что совсем уже в голове не укладывается, - почему формат задания маски в строке поиска файлов не имеет право гордо называться, скажем, языком запроса файловой системы Упреждая последующие возгласы не согласия поясняю на примере:
выбрать все записи из таблицы Машины

найти все файлы, начинающиеся на test и имеющие любое расширение

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

Просьба не считать это выговором, упреком или чем-то еще - просьба всего лишь называть вещи своими именами и не расказывать сказки про проффесиональных программистов, которые в состаяние выучить 10 языков программирования.


можно конечно, если продумать структуру хорошенько.