Здравствуйте, ecinunice, Вы писали:

E>Здравствуйте, vabe, Вы писали:

V>>Кстати, если кому-то нужен http://code.google.com/p/expemerent/ исправленный для текущей версии Sciter, я могу поделиться.

E>Если не сложно, поделитесь; модификацию для WM делали?

Для WM нет. Там нет реализации для Sciter на WM (только для HTMLayout). Судя по всему HTMLayout не сильно изменился, поэтому код возможно будет работать и с обновленными версиями.

Здравствуйте, vabe, Вы писали:

V>Для WM нет. Там нет реализации для Sciter на WM (только для HTMLayout). Судя по всему HTMLayout не сильно изменился, поэтому код возможно будет работать и с обновленными версиями.

Сложно быть не должно. Лично я упёрся только в отсутствие маршалинга для ANSI строк. В итоге родилось такое

    public sealed class MarshalCF
    {
        unsafe public static string PtrToStringAnsi(IntPtr ptr)
        {
            byte* lpStart = (byte*)ptr;
            byte* lpEnd = lpStart;

            for (; *lpEnd != 0; ++lpEnd)
            {
            }

            Decoder decoder = Encoding.ASCII.GetDecoder();
            char[] buffer = new char[decoder.GetCharCount(lpStart, (int)(lpEnd - lpStart), true)];

            fixed (char* lpBuffer = buffer)
            {
                decoder.GetChars(lpStart, (int)(lpEnd - lpStart), lpBuffer, buffer.Length, true);
            }

            return new string(buffer, 0, buffer.Length);
        }

        unsafe public static IntPtr StringToHGlobalAnsi(string value)
        {
            Encoder encoder = Encoding.ASCII.GetEncoder();

            fixed (char* lpValue = value)
            {
                int stringLength = encoder.GetByteCount(lpValue, value.Length, true);
                IntPtr lpString = Marshal.AllocHGlobal(stringLength);

                encoder.GetBytes(lpValue, value.Length, (byte*)lpString, stringLength, true);

                return lpString;
            }
        }
    }

Используйте на здоровье

Здравствуйте, adontz, Вы писали:

A>Сложно быть не должно. Лично я упёрся только в отсутствие маршалинга для ANSI строк. В итоге родилось такое

Спасибо. Ваш код я видел давно (с той поры как он на google). Дело не в проблеме написания обертки,
кроме того в вышеупомянутом проекте есть обертка над HTMLayout для WM. Дело в целесообразности SCITER для WM
и в том, что на terrainformatica последний sciter для WM датирован осенью 2007 года (который по части API кардинально
отличается от текущей версии)

Здравствуйте, vabe, Вы писали:

V>Спасибо. Ваш код я видел давно (с той поры как он на google).

У меня зарождается мания преследования. Всё-то он видел...

V>Дело в целесообразности SCITER для WM

HTMLayout на WM есть, Lua в C++ проекте для покетов я видел. Думаю moSciter не такая уж бесполезная штукенция.

V>и в том, что на terrainformatica последний sciter для WM датирован осенью 2007 года (который по части API кардинально отличается от текущей версии)

О, посмотри сколько мы просили 64итный билд HTMLayout Каждая новая платформа это сложно и я Андрея в этом очень хорошо понимаю. Мне вот, элементарно, NT и CE версию поддерживать сложно, постоянно ломаю билды. А ещё, бывает, 2005 студия у кого-то...

Здравствуйте, adontz, Вы писали:

V>>Дело в целесообразности SCITER для WM
A>HTMLayout на WM есть, Lua в C++ проекте для покетов я видел. Думаю moSciter не такая уж бесполезная штукенция.

Я немного не досказал мысль — целесообразности обертки для .NET над moSciter для WM. Там итак все плохо с ресурсами. Судя по всему
его надо использовать как есть (на C или С++)

Здравствуйте, vabe, Вы писали:

V>Здравствуйте, adontz, Вы писали:

V>>>Дело в целесообразности SCITER для WM
A>>HTMLayout на WM есть, Lua в C++ проекте для покетов я видел. Думаю moSciter не такая уж бесполезная штукенция.

V>Я немного не досказал мысль — целесообразности обертки для .NET над moSciter для WM. Там итак все плохо с ресурсами. Судя по всему
V>его надо использовать как есть (на C или С++)

Сгласный я. Кузнец на том сеновале нам не нужен.

Здравствуйте, adontz, Вы писали:

CS>>Да понимаешь... если твоя система, как стадо макак, только и умеет что гадить квадратно гнездовым методом то тогда да, тебе нужен супер-пупер многопоточный garbage коллайдер который умеет на нюх различать поколения макакских эскрементов. Но если твоя система состит из индивидов с интеллектом то задача уборки территории состоит в тривиальном опустошении урн и биотуалетов.
CS>>Я доходчиво концепт изложил?

A>Да, я только не понял почему System.Object тупая макака, а вот объект TIScript — индивид с интеллектом.

Чего стоит твоему GC вот эта макака?
http://www.java2s.com/Code/CSharp/2D-Graphics/GradientLabelHost.htm —
простое же дело в принципе — label с gradient. Но вот этой лэйбочке нужно только для работы 7(семь) gc-able и disposable объектов.
Для встраивания в IDE еще пара классов нужна. Итого получаем требование иметь супер-GC за для просто порисовать.

Я про это.

CS>>Ну дык и я о том — есть UI его пишем в терминах легко модифицируемо настраиваемых HTML/CSS/Script ибо это величина переменная по определению.
CS>>Но есть и логика — некий черно-ящичный-конечный-автомат подключенный к безобразию UI через контролируемый шлюз. И неважно находятся эти UI и логика внутри одного процесса или разнесены по сетке — принципы должны быть те же. Layers придуманы не на пустом месте.

A>В .Net контролируемым шлюзом является observable model, какой-нибудь IBindingList. В Си++ родных событий нет и механизм не прижился.
A>На самом деле такой шлюз очень удобен, я полностью контролирую все действия UI, могу отменить любое изменение или скорректировать его, с одной стороны. С другой стороны меня не принуждают к формату хранения, коллекция даже не обязательно должна быть целиком в памяти. Я использую это на практике, реально пишу на порядок меньше кода, чем с ручным перекидыванием данных в UI и обратно. Описывается всё тоже замечательно.
A>

A>MyDataGrid.DataSource = MyCollection;
A>

A>Он сам вытянет элементы, спросит у коллекции ReadOnly и если да, то спрячет кнопку Add New.
A>Собственно, если взять Nabu.Collections.BindingListEx вместо стандартного, то там вообще можно творить чудеса

Ну дык!

Мега-проблема с универсальными компонентами — универсальное решение всегда избыточно для каждой конкретной задачи.
Всегда найдется частное решение которое будет эффективнее универсального.
Т.е. в принципе не существует, скажем, идеального грида. В каждом частном случае нужно нечто свое.
Всё что можно универсализировать здесь это дать систему кубиков (DOM/CSS) и дать способ их и их событий связывать по-всякому.

Здравствуйте, c-smile, Вы писали:

CS>Чего стоит твоему GC вот эта макака?
CS>http://www.java2s.com/Code/CSharp/2D-Graphics/GradientLabelHost.htm —
CS>простое же дело в принципе — label с gradient. Но вот этой лэйбочке нужно только для работы 7(семь) gc-able и disposable объектов.
CS>Для встраивания в IDE еще пара классов нужна. Итого получаем требование иметь супер-GC за для просто порисовать.
CS>Я про это.

В .Net всё сводиться либо к unmanaged GDI+, либо к, по сути, тоже unmanaged WPF. То есть твою аргументацию я на 100% принимаю, но и в Майкрософте не дураки

CS>Мега-проблема с универсальными компонентами — универсальное решение всегда избыточно для каждой конкретной задачи.
CS>Всегда найдется частное решение которое будет эффективнее универсального.
CS>Т.е. в принципе не существует, скажем, идеального грида. В каждом частном случае нужно нечто свое.
CS>Всё что можно универсализировать здесь это дать систему кубиков (DOM/CSS) и дать способ их и их событий связывать по-всякому.

Ты прав, но есть один важный момент. Программист выучивший стандартное, пусть и избыточное, решение дешевле и заменяемее гения, клепающего оптимальные решения из примитивных кубиков. Индустрии нужны стандарты. Если не будет стандартов навязываемых извне, будут внутрикорпоративные, но какие-то будут всё равно. Лучше, навязываемые извне, тогда компания сможет нанимать людей общаясь с ним на одном языке.

Так что лучше бы тебе дать людям мегарешение "от автора", гении не все. А где украсть, я уже сказал

Здравствуйте, vabe, Вы писали:

V>Я немного не досказал мысль — целесообразности обертки для .NET над moSciter для WM. Там итак все плохо с ресурсами. Судя по всему его надо использовать как есть (на C или С++)

Честно говоря, в скорость рендеринга HTMLayout я на покетах упирался гораздо чаще, чем в скорость работы .Net CF. А вот write once, run everywhere некоторую категорию разработчиков всегда привлекало.