Russian Qt Forum

Здравствуйте

Не сейчас, но в ближайшем будущем мне предстоит решить проблему хорошей/эффективной демо-версии. Накоплен кое-какой опыт. Предыдущее демо строилось по принципу вырезания фичес, напр.

C++ (Qt)
#if DEMO_VERSION
 Alert("You cannot save project in demo version, sorry");
#else 
 DoSaveProject();
#endif
 

Жизнь показала что такое демо действительно безопасно (кода DoSaveProject() в демо-файле((exe) нет, что-то "ломать" нет смысла). Но с др. стороны такое демо и малоэффективно - пользователь не может понять то ли "это демо" то ли "вообще не работает"  :'( Все согласны с тем что демо должно иметь максимум 1-2 ограничений. Но как это сделать? Пример:

- можно отрубить запись данных на диск (показано выше). Но это "слишком жестко"

- хорошо было бы разрешать "ограниченную" запись на диск. Напр. до 1 Мb - пиши пожалуйста. Больше - извини, это демо. Но проверка if - легкая добыча, такое демо превратится в полноценную версию через неделю (если не быстрее)

Как бы порешать этот вопрос?

Спасибо

А что за приложение?

Нормальное, на Mac имеет суффикс .app, на Вындоуз .exe  :)

Тогда, собственно, не вижу проблем почему вы не можете сделать что просите)))) а? ;D

Ну как бы речь идет о том, что оно делает :) ведь самый правильный подход - убрать или ограничить в демо то, что является либо "сильным удобством", либо "солью приложения". А так - что тут посоветовать то? Особо ничего, т.к. вообще не в курсе о чем речь :))

>>убрать или ограничить в демо то, что является либо "сильным удобством", либо "солью приложения".
тогда пользователь не сможет оценить приложение, оно будет такое же как и у всех

я видел такую фишку в одной из программ - Имеются ограничения на использование фалов данных:
1) демка сохраняет данные в нестандартный формат, который не читается нормальным приложением.
2) Демка также не понимает формат нормального приложения.
3) Есть предел у файла, но не по размеру в байтах, а по размеру сущностей, которые хранятся в файле или их комбинации

не, не все так просто. Грамотный подход к делу дает сделать именно "демо", при этом показав его возможности. Но тут уже нужно знать что за приложение и т.п. Я же не просто говорю "отсечь самое вкусное" - это то точно неправильный подход :)

Ну вот в GTP все правильно - можно сделать партитуру, прослушать ее, навешать всех-всех эффектов, а вот сохранить, как и открыть готовые, нельзя. То есть ознакомится можно со всеми возможностями, а вот пользоваться невозможно.

Ну не надо притворяться что, мол, ничего не понял  :) Чего в демо не должно быть - сказано ясно: надо ограничить запись на диск. Полностью ее отрезать - не вопрос, но не хотелось бы, так я заставляю каждый раз начинать демо с нуля, неудобно. Вопрос в том как ограничить "мэртво" чтобы попытки взлома не имели смысла.

По количеству сохраненных объектов - было бы еще лучше. Но все проблемы остаются те же.

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

советовать "как ограничить сохранение для абстракции" - увы, дело гиблое. Есть "традиционные" способы, но они Вас видимо не устраивают. А чтобы придумать что-то нетрадиционное и удобное - надо иметь представление о программе.

Не могу с Вами согласиться что конкретно здесь надо вникать в предметную область. Представим себе контейнер <QString>. Как я могу сохранить не более 100 элементов? (с учетом позывов взломать). Конечно, в реальном проекте куда более сложные объекты (вместо QString) - но что это меняет? По мне так аж ничего, зачем же тогда тратить время на долгие экскурсии в специфику задачи?

Дело совсем не выглядит безнадежным, ходы есть. Я прикидывал напр так:

- запись = "поток", значит я могу сделать класс "поток - запись в память". Выделил 1 Mb памяти, пишу в этот буфер. По ходу дела пишущий вызывает 1-2 раза какие-то методы что будут работать для "потока - память" но не для "потока - файл", это легко

- запись в буфер закончена, теперь просто копируем созданный  "образ" на диск.

Это конечно, сырые идеи, напр неясно как сделать так чтобы размер буфера никак нельзя было изменить. Или можно как-то проще/лучше? Блин, Вы в конце-концов будете думать головой, а не только маны читать?  :)

Чтобы размер буфера нельзя было изменить, надо чтобы программа где-то в расчетах использовала это значение, тогда при измененном буфере будут неверные расчеты.

На уровне заготовки идеи.
Преопределить в демоверсии какой либо стандартный класс, да сбственно, наверное и любой. Нуи какелибо "неадекватное" действие зашить: рисвоть диагональную черту, заменят все буквы "а" на букву "ё". Сложение чисел где то покорежить... ну в общем нужно знание о чем программа и фантазии

Ну вот, один вариант уже есть  :) Только наверное не значение (переменная) а хвост буфера, если изменился - валим, здесь никаких сообщений показывать не нужно (это я сделаю раньше)

В данном случае не очень подходит, UI большое, получается хлопотно

Для программки, работающей с документами, можно ограничить число одновременно открытых. Например, 5 штук.
Чтобы сообщение было: "а вот больше 5 - нельзя, ибо демо!".

Если сломают, ничего: в другом месте сравниваешь уже не с 5, а с 7 (например), и не обламываешь юзера, а делаешь бред: например, открываешь (сохраняешь) совсем другой документ.

А еще можно лишить юзера какой-нибудь маленькой радости. Пусть программка будет полнофункциональна, но без проверки орфографии. Ну нафиг она ему не сдалась, но будет "звоночек" в голове у человека.