Если я понимаю право, Ваша самая большая проблема с анализом экранных данных, не самой автоматизированной покупкой.
Если так, Ваш самый эффективный шаг должен был бы победить анализ экранных данных путем случайного кодирования страницы так, чтобы это выглядело одинаково (отчасти), но всегда отличается на уровне кода. (используйте шестнадцатеричные коды, кодирование Java, изображения, изменение, окружающее структуру кода...)
, Который вынудил бы их постоянно переписать свой код очистки и поэтому сделать его, что намного более дорогой, чтобы они купили Ваше "дерьмо" автоматически. Если они могут справиться. Они, вероятно, продолжили бы поражать Ваш веб-сайт некоторое время, пока они не понимают, что ничего не могут получить от него и отбросить его.
оборотная сторона путания ада из ботов - то, что это также перепутает ад из поисковых роботов поисковой системы.
Границы в IE округляются только тогда, когда 1) у вас включен параметр «Использовать визуальные стили в окнах на кнопках» в разделе «Производительность | Вкладка "Визуальные эффекты". Проще говоря: если у вас включена «тематика XP», оно будет округлено, когда у вас классический вид Win2000, оно не будет округлено.
Второе требование 2) - «отсутствие CSS, связанного с границами» для набор полей. Всякий раз, когда вы назначаете цвет границы, или стиль границы, или ширину границы, «округлость» исчезает, для этого нет обходного пути. То же самое касается ввода (как кнопок, так и полей), текстового поля и тегов выбора. Всякий раз, когда IE не находит CSS-темы для элемента управления для визуализации, он применяет к элементу «тему Windows по умолчанию».
Я не рекомендую это, как и остальные ответы, где достигается прямой доступ к контроллеру представления Нет встроенного способа сделать это. Хотя вы можете обойти это, добавив IBOutlet
в UIView
и подключив их в Interface Builder, это не рекомендуется. Представление не должно знать о контроллере представления. Вместо этого вы должны сделать так, как предлагает @Phil M, и создать протокол, который будет использоваться в качестве делегата.
Нет никакого способа.
Я просто передаю указатель UIViewController в UIView (или соответствующее наследование). Извините, я не могу помочь с подходом IB к проблеме, потому что я не верю в IB.
Чтобы ответить первому комментатору: иногда вам действительно нужно знать, кто вам звонил, потому что это определяет, что вы можете сделать . Например, с базой данных у вас может быть доступ только для чтения или чтения / записи ...
Хотя технически это можно решить, как рекомендует pgb , ИМХО, это недостаток конструкции. Представлению не нужно знать о контроллере.
Мое решение, вероятно, сочли бы своего рода подделкой, но у меня была ситуация, аналогичная mayoneez (я хотел переключать представления в ответ на жест в EAGLView), и я получил контроллер представления EAGL следующим образом:
EAGLViewController *vc = ((EAGLAppDelegate*)[[UIApplication sharedApplication] delegate]).viewController;
UIView
является подклассом UIResponder
. UIResponder
представляет метод -nextResponder
с реализацией, которая возвращает nil
. UIView
переопределяет этот метод, как описано в UIResponder
(по какой-то причине вместо UIView
) следующим образом: если представление имеет контроллер представления, он возвращается Автор -nextResponder
. Если нет контроллера представления, метод вернет супервизор.
Добавьте это в свой проект, и все готово.
@interface UIView (APIFix)
- (UIViewController *)viewController;
@end
@implementation UIView (APIFix)
- (UIViewController *)viewController {
if ([self.nextResponder isKindOfClass:UIViewController.class])
return (UIViewController *)self.nextResponder;
else
return nil;
}
@end
Теперь UIView
имеет рабочий метод для возврата контроллера представления.