Есть у меня такой класс(для работы с трэем):

class CNotifyIcon {
  public:
    CNotifyIcon ();
    ~CNotifyIcon ();
    Modify();
  private:
     NOTIFYICONDATA * NotifyIconData;
};

CNotifyIcon::CNotifyIcon() {
  NotifyIconData = new NOTIFYICONDATA; //все нормально
  (*NotifyIconData).hIcon = Icon1;
  (*NotifyIconData).uCallbackMessage = wm_NotifyIcon;
  (*NotifyIconData).uFlags = NIF_ICON | NIF_MESSAGE;
  (*NotifyIconData).uID = 1;
  (*NotifyIconData).hWnd = hЦnd;
  (*NotifyIconData).cbSize = sizeof(*NotifyIconData);

  Shell_NotifyIcon(NIM_ADD, NotifyIconData); //иконка создается
};

CNotifyIcon::~CNotifyIcon() {
  Shell_NotifyIcon(NIM_DELETE, NotifyIconData);
  delete NotifyIconData;
};

CNotifyIcon::Modify(unsigned Number) {
  (*NotifyIconData).hIcon = Icon1; //ошибка Access violation
  Shell_NotifyIcon(NIM_MODIFY, NotifyIconData);
}

В чем дело — не понимаю
Помогите побороть

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

Для начала напиши оператор присваивания и конструктор копирования.

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

_>В чем дело — не понимаю
_>Помогите побороть

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

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

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

B>Для начала напиши оператор присваивания и конструктор копирования.

А зачем? В каком месте они требуются?

Вероятно, каким-то образом Modify() вызывается для удаленного объекта.

Здравствуйте, Вадим Никулин, Вы писали:

ВН>Скорее всего, Modify вызывается после деструктора. Ты бы кода побольше показал, тогда можно конкретнее сказать.

Вызывается Modify до деструктора, а код примерно такой:

CNotifyIcon * TrayIcon = new CNotifyIcon();
TrayIcon->Modify();

Так явно — нет memset(NotifyIconData, 0, sizeof(NOTIFYICONDATA)); перед началом заполнения. В итоге у тебя в чати полей мусор остается, в таких как szTip например, что черевато, поскольку это нулем закрытая строка.

А вообще выложи еще пример, как ты его юзаешь. Действительно сильно похоже, что ты зовешь метод с объекта, который уже разрушился.

Всех благ. Артем.

Здравствуйте, Вадим Никулин, Вы писали:

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

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

B>>Для начала напиши оператор присваивания и конструктор копирования.

ВН>А зачем? В каком месте они требуются?
Очень вероятно, что где-то с помошью оператора присваивания или конструктора копирования создается временный объект, после смерти которого разрушается элемент NotifyIconData объекта-источника.

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

_>Есть у меня такой класс(для работы с трэем):

В качестве хинта: а зачем вообще создавать структуру на куче? Она же небольшая, можно прямо в теле объекта разместить.

class CNotifyIcon
{
private:
  NOTIFYICONDATA data;
public:
  .....
}

1. Обнуляй структуру перед инициализацией.
2. Убедись что Icon1 — это реальный дескриптор иконки.

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


S> 1. Обнуляй структуру перед инициализацией.
Это правильно.

S> 2. Убедись что Icon1 — это реальный дескриптор иконки.
А вот из-за этого access violation быть не может

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

К>В качестве хинта: а зачем вообще создавать структуру на куче? Она же небольшая, можно прямо в теле объекта разместить.
К>

К>class CNotifyIcon
К>{
К>private:
К>  NOTIFYICONDATA data;
К>public:
К>  .....
К>}
К>

Включать структуру по указателю полезно с целью уменьшения времени компиляции. Стандартные h-файлы не засоряют твои и и прекомпилляция работает более эффективно.

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

_>Есть у меня такой класс(для работы с трэем):
_>

_>class CNotifyIcon {
_>  public:
_>    CNotifyIcon ();
_>    ~CNotifyIcon ();
_>    Modify();
_>  private:
_>     NOTIFYICONDATA * NotifyIconData;
_>};

...

_>CNotifyIcon::Modify(unsigned Number) {
_>  (*NotifyIconData).hIcon = Icon1; //ошибка Access violation
_>  Shell_NotifyIcon(NIM_MODIFY, NotifyIconData);
_>}
_>

_>В чем дело — не понимаю
_>Помогите побороть

Посмотри в debuggere, чему равен this в ф-ции Modify.
Не мешает пояснить, что такое Icon1.