-
Добрый вечер!
Такая проблема нарисовалась... Есть сторонняя DLL. Ей надо передавать файл в виде IStream.
А я со всякими "I" прежде не работал. Нашёл вот такой код:
var StreamM: TMemoryStream; StreamI: IStream; NewPos: Int64;
begin
StreamM.LoadFromFile('...');
StreamI:=TStreamAdapter.Create(StreamM, soReference) as IStream;
StreamI.Seek(0, 0, NewPos);
// Ура! Теперь у нас есть IStream! Передаём куда нужно!
Но не работает - пишет мол нет информации об имени файла. Поддержка ответила что библиотека делает IStream.Stat() и ожидает имя файла в поле TStatStg.pwcsName, обязательно.
Может можно как-то проще загрузить файл с диска сразу в IStream, и без конвертаций и чтоб в TStatStg тоже было всё нормально? Подскажите, пожалуйста.
-
Надо пригласить А.С.Пушкина и он с удовольствием заполнит свойство TStreamAdapter.Stat
-
эм... TStreamAdapter.Stat() - это не свойство, а функция, возвращающая (вернее заполняющая структуру) информацию, а не устанавливающая её...
-
Видимо либо придётся делать наследника TStreamAdapter с перекрытым Stat (что как-то не хочется возиться), либо искать принципиально другой способ...
Цель: загрузить файл с диска в виде IStream и обязательно с актуальным tagSTATSTG.
Может кто подскажет? Подозреваю должен быть системный ComObject, который подойдёт... Название его бы мне... %)
-
А.С.Пушкин вообще сильно удивлён, что вы изволите требовать от TMemoryStream имя какого-то файла.
-
Да хоть TMemoryStream, хоть TFileStream, хоть TBufferedFileStream - без разницы.
Нигде не запоминается TStatStg и не предусмотрено возможности заполнить вручную.
TStreamAdapter также сего не реализует вообще никак.
Если не знаете ответа - зачем вообще что-либо писать? =/
-
Как это не предусмотрено? Перекрываешь метод IStream.Stat и возвращаешь на вызове этого метода заполненную структру.
-
Необходимость чего-то там перекрывать и фактически реализовывать вручную - как раз и есть "не предусмотрено". :)
Мне бы как раз не хотелось "наследовать и допиливать". Есть ли подходящий ComObject? Всё равно в данном подпроекте их использую пачками...
-
> Прохосый (15.06.18 11:00) [7]
Ты бы хоть, перед плачем, прочитал что-такое интерфейсы и для чего они созданы.
PS. В описании конкретно описано кто что должен реализовывать.
-
> Прохосый (14.06.18 18:07) [5]
>
> Если не знаете ответа - зачем вообще что-либо писать? =/
Как можно ответить тому, кто ответа всё-равно не понимает?
-
1.Не загружать файл в НЕсуществующий объект streamM.LoadFromFile(имя файла)
а СОЗДАВАТЬ файловый поток streamM:=TFileStream.Create(имя файла);
2. и уже его(stremM), существующий и знающий про имя файла, отдавать TStreamAdapter.Create(streamM);
-
> В описании конкретно описано кто что должен реализовывать.
TStreamAdapter должен был реализовать. А реализовал частично. Я не собираюсь его допиливать:
Чтоб мне потом полгода отчёты писать, почему вместо TStreamAdapter был использован TStreamAdapterEx, которого стандартная Делфи знать не знает?
> в НЕсуществующий объект
Это просто кусок примера. Ну забыл многоточие.. Если бы не был создан объект, было бы AV, а не "отсутствие информации".
TFileStream как раз НЕ знает про имя файла (и никакой потомок TStream не знает имя файла). А этот TStreamAdapter тоже не поддерживает указание такой информации вручную...
Ещё раз - надо загрузить файл с диска в виде IStream, обязательно с актуальным tagSTATSTG, что-либо наследовать от TStreamAdapter нельзя.
-
> Прохосый (15.06.18 19:01) [11]
>
> > В описании конкретно описано кто что должен реализовывать.
>
>
> TStreamAdapter должен был реализовать. А реализовал частично.
> Я не собираюсь его допиливать:
Вам бы программиста нанять.
> что-либо наследовать от TStreamAdapter нельзя.
Я ешё больше скажу, для решения и TStreamAdapter не нужен.
-
> Прохосый (15.06.18 19:01) [11]
>
> > В описании конкретно описано кто что должен реализовывать.
>
>
> TStreamAdapter должен был реализовать. А реализовал частично.
> Я не собираюсь его допиливать:
Вам бы программиста нанять.
> что-либо наследовать от TStreamAdapter нельзя.
Я ешё больше скажу, для решения и TStreamAdapter не нужен.
-
> Прохосый (15.06.18 19:01) [11]
>
> > В описании конкретно описано кто что должен реализовывать.
>
>
> TStreamAdapter должен был реализовать. А реализовал частично.
> Я не собираюсь его допиливать:
Вам бы программиста нанять.
> что-либо наследовать от TStreamAdapter нельзя.
Я ешё больше скажу, для решения и TStreamAdapter не нужен.
-
А вам бы в отпуск съездить, кислый вы человек.
Прямо передо мною исходный код библиотек Делфи. А также исходный код библиотек Лазаруса.
Я глазами вижу что TStreamAdapter без доработок вручную никак не позволяет сделать то что мне нужно.
> для решения и TStreamAdapter не нужен
Ну так скажите как, а то только ехидничаете, а по делу-то ни слова.
Я предполагаю что есть подходящий ComObject. Но мне неизвестно какой. Прошу же уже скока название подсказать! =/
-
А вам бы в отпуск съездить, кислый вы человек.
Прямо передо мною исходный код библиотек Делфи. А также исходный код библиотек Лазаруса.
Я глазами вижу что TStreamAdapter без доработок вручную никак не позволяет сделать то что мне нужно.
> для решения и TStreamAdapter не нужен
Ну так скажите как, а то только ехидничаете, а по делу-то ни слова.
Я предполагаю что есть подходящий ComObject. Но мне неизвестно какой. Прошу же уже скока название подсказать! =/
-
А вам бы в отпуск съездить, кислый вы человек.
Прямо передо мною исходный код библиотек Делфи. А также исходный код библиотек Лазаруса.
Я глазами вижу что TStreamAdapter без доработок вручную никак не позволяет сделать то что мне нужно.
> для решения и TStreamAdapter не нужен
Ну так скажите как, а то только ехидничаете, а по делу-то ни слова.
Я предполагаю что есть подходящий ComObject. Но мне неизвестно какой. Прошу же уже скока название подсказать! =/
-
> Я предполагаю что есть подходящий ComObject.
И этого не нужно.
Нужно просто запрограммировать класс, реализуюший интерфейс IStream. Но для этого требуется программист.
-
> Я предполагаю что есть подходящий ComObject.
И этого не нужно.
Нужно просто запрограммировать класс, реализуюший интерфейс IStream. Но для этого требуется программист.
-
> Я предполагаю что есть подходящий ComObject.
И этого не нужно.
Нужно просто запрограммировать класс, реализуюший интерфейс IStream. Но для этого требуется программист.
-
Вам точно надо в отпуск. Читаете предложение через три. Нельзя этого делать. По заданным ограничениям. Запретили.
А даже если бы можно бы было - нафига почти идентично повторять реализацию TFileStream/TMemoryStream и TStreamAdapter..?
Я бы уже давным-давно просто подправил TStreamAdapter. Как сам же написал ещё в [3]. Но запрещено.
-
Вам точно надо в отпуск. Читаете предложение через три. Нельзя этого делать. По заданным ограничениям. Запретили.
А даже если бы можно бы было - нафига почти идентично повторять реализацию TFileStream/TMemoryStream и TStreamAdapter..?
Я бы уже давным-давно просто подправил TStreamAdapter. Как сам же написал ещё в [3]. Но запрещено.
-
Вам точно надо в отпуск. Читаете предложение через три. Нельзя этого делать. По заданным ограничениям. Запретили.
А даже если бы можно бы было - нафига почти идентично повторять реализацию TFileStream/TMemoryStream и TStreamAdapter..?
Я бы уже давным-давно просто подправил TStreamAdapter. Как сам же написал ещё в [3]. Но запрещено.
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
TStreamAdapter - это уже "класс, реализующий интерфейс IStream". Только совершенно не продумали необходимость работать с TStatStg...
А наследовать и перекрывать - нельзя. Запрещено. Как говорится "по условиям задачи".
Зато разрешены CreateComObject() с Supports(). Бывает подходящий ComObject или нет?
-
Упс, глюк какой-то... Сотрите пожалуйста [17], [18], [19]...
-
Упс, глюк какой-то... Сотрите пожалуйста [17], [18], [19]...
-
Упс, глюк какой-то... Сотрите пожалуйста [17], [18], [19]...