Просто второй год сижу без аськи и вполне удобно урлами обмениваюсь.
Хотел уточнить, может у нас какие-то разные урлы, раз товарищу ими неудобно обмениваться кроме как по аське.
Имхо, деловая переписка по аське — это несолидно, не говоря уже о том, что (возможно, конфиденциальные) данные гоняются через пол-планеты по незащищенным каналам.
Для общения с клиентами есть почта и телефон.
Я на свой айТач на заднюю крышку наклейку наклеил.
Потому что «as is» это зеркало залапывается (и, наверное, в отличие от экрана, царапается), а так — и красиво, и функционально, и на ощупь приятно.
Хотя, какие, к черту, уровни? Вот вам О(n2) даже без всяких динамических джаваскриптов:
function $(id) { return document.getElementById(id); }
function $attr(x, y) {
var attr = (x.attributes) ? x.attributes[y] : null;
return (attr) ? attr.value : null;
}
var comments = $("comments").getElementsByTagName("div");
for (var i = 0; i < comments.length; i++) {
var x = comments[i];
if ($attr(x, "class") != "comment") continue;
var parentId = $attr(x, "parentId");
if (!parentId) continue;
Впрочем, можно и за О(n2) сделать. Например, не делать getElementById для каждого комментария, а просто цикл по верхнему уровню, а getElementById применять только для нахождения parent-а. Правда, тогда нужно иметь уровень вложенности элемента еще (для сортировки), а не только id parent-а.
Не очень понятно, откуда взялось O(n3). Если считать, что getElementById() — это O(n), то O(n2) получается. Хотя, конечно, все зависит от конкретной реализации DOM.
Да и запрос в базу тут один. И даже выдачу элементов и формирование джаваскриптов можно за один проход делать.
Да, только зачем рекурсия на сервере?
Для выборки всех комментариев топика она не нужна, у комментария и так должно быть поле, определяющее принадлежность к топику.
1) Вполне легально, иначе бы не было кучи коммерческих контролов.
2) Вообще под «готовым решением» я предполагал соответствующий набор классов, а не просто документацию :) Тоже вполне легально.
Например, сам MS предоставляет бесплатные Ribbon контролы для MFC (в составе MSVC 2008 Feature Pack) и WPF (пока в стадии беты, но уже вполне юзабелен).
Бесплатный Ribbon для Windows.Forms есть как сторонняя разработка на CodeProject-е.
Помимо этого, как уже было сказано, есть много коммерческих решений.
Решение этой проблемы было положено на File Virtualization.
Вообще разработчики софта должны были заранее головой думать. Хотя вот разработчики QiP-а, кажется, до сих пор этого не поняли…
Там не просто подгонка размера, там различные стратегии по переключению режима в зависимости от размера.
То есть вот были, например, три большие кнопки с текстом. Потом им стало не хватать места, они делаются тремя маленькими с текстом и лейаутятся в столбик. Потом, когда места снова не хватает, может отключаться текст, и остаются только иконки.
При это можно указывать, какие кнопки можно, а какие нельзя так изменять, etc.
ПИнвок предполагает маршаллинг типов в процессе вызова, что в общем и приводит к потере производительности.
А вот при вызове managed -> unmanaged (или наоборот) из, скажем, C++/CLI, маршаллинг не применяется, а просто соблюдается соответствующая конвенция вызова.
Хотел уточнить, может у нас какие-то разные урлы, раз товарищу ими неудобно обмениваться кроме как по аське.
Для общения с клиентами есть почта и телефон.
Потому что «as is» это зеркало залапывается (и, наверное, в отличие от экрана, царапается), а так — и красиво, и функционально, и на ощупь приятно.
соответственно, комментарии выдаются блоком вида:
Да и запрос в базу тут один. И даже выдачу элементов и формирование джаваскриптов можно за один проход делать.
Для выборки всех комментариев топика она не нужна, у комментария и так должно быть поле, определяющее принадлежность к топику.
2) Вообще под «готовым решением» я предполагал соответствующий набор классов, а не просто документацию :) Тоже вполне легально.
Например, сам MS предоставляет бесплатные Ribbon контролы для MFC (в составе MSVC 2008 Feature Pack) и WPF (пока в стадии беты, но уже вполне юзабелен).
Бесплатный Ribbon для Windows.Forms есть как сторонняя разработка на CodeProject-е.
Помимо этого, как уже было сказано, есть много коммерческих решений.
Раз цель достигнута, то смысла в этом нет. :)
Вообще разработчики софта должны были заранее головой думать. Хотя вот разработчики QiP-а, кажется, до сих пор этого не поняли…
То есть вот были, например, три большие кнопки с текстом. Потом им стало не хватать места, они делаются тремя маленькими с текстом и лейаутятся в столбик. Потом, когда места снова не хватает, может отключаться текст, и остаются только иконки.
При это можно указывать, какие кнопки можно, а какие нельзя так изменять, etc.
Уверены, что хотите с нуля это создавать? :)
Не лучше ли воспользоваться готовым решением?
А вот при вызове managed -> unmanaged (или наоборот) из, скажем, C++/CLI, маршаллинг не применяется, а просто соблюдается соответствующая конвенция вызова.
Вопрос был о том, с чего вы решили, что для вызова анменеджеда используется p/invoke?
Зачем, например, указывать CharSet.Auto на функциях, которые и со строками-то не оперируют вовсе? :)