Follow-up:

Executing progressbar (or any other) example,
I get zillions of these messages:

Exception=Unknown Run-Time error : 217
TApplication.HandleException: there was another exception during showing the first exception [FORMS.PP] ExceptionOccurred
Sender=EXCEPTION
Exception=Unknown Run-Time error : 217

So something is definitely wrong in the windows interface:/

Michael.

Bottom-Up or Top-Down are both logical and should be supported by the interfaces. But for readability and debugging I changed it.

First check/attach parent, then create children? I am asking this because win32object.attachmenu uses the parent of the parent and I am not sure whether it is initialized at all times, ie. the children are attached to parents.

What do you need to fix that?

Ultimate reason: the win32 interface seems to crash when a shortcut is set for a particular menuitem. It occurs when running the lazarus ide.

I'm sure you will find the bug.

Apropos IDE: Did you try the TSynEdit under win32?

Mattias

I did, with todays sources:

malpertuus: /cygdrive/e/pp/projects/lazarus/examples >./edittest [FORMS.PP] ExceptionOccurred
Sender=EACCESSVIOLATION
Exception=Access violation
TApplication.HandleException Access violation
TApplication.HandleException Handling "Access violation" ... [FORMS.PP] ExceptionOccurred

Not very informative :-/

Michael.

Hi,

Currently, TMenuItem.CreateHandle looks like this:

---
  SendMsgToInterface(LM_CREATE, Self, nil);
  if FItemsnil then begin
    for i := 0 to Count - 1 do begin
      Items[i].HandleNeeded;
    end;
  end;
  if Parent  nil then
  begin
    Parent.HandleNeeded;
    if Parent.HandleAllocated then
      SendMsgToInterface(LM_ATTACHMENU, Self, nil);
    if HandleAllocated then begin
      if ShortCut  0 then ShortCutChanged(0, Shortcut);
    end;
  end;
---

It first creates the children, then attaches to parent. Wouldn't it be more logical to do it the other way around? First check/attach parent, then create children? I am asking this because win32object.attachmenu uses the parent of the parent and I am not sure whether it is initialized at all times, ie. the children are attached to parents.

Ultimate reason: the win32 interface seems to crash when a shortcut is set for a particular menuitem. It occurs when running the lazarus ide.

Thanks,

Micha.

Seems reasonable.

I am wondering about the following piece of code from win32object.attachmenu:

---
  {Following part fixes the case when an item is added in runtime
  but the parent item has not defined the submenu flag (hSubmenu=0) }
  if (Sender as TMenuItem).Parent.Parentnil then
  begin
    ParentOfParent := (Sender as TMenuItem).Parent.Parent.Handle;
    with MenuInfo do begin
      cbSize:=sizeof(MENUITEMINFO);
      fMask:=MIIM_SUBMENU;
    end;
    GetMenuItemInfo(ParentOfParent, (Sender as TMenuItem).Command,
                    false, @MenuInfo);
    if MenuInfo.hSubmenu=0 then // the parent menu item is not yet defined
with submenu flag
    begin
      MenuInfo.hSubmenu:=ParentMenuHandle;
      SetMenuItemInfo(ParentOfParent, (Sender as TMenuItem).Command,
                      false, MenuInfo);
    end;
  end;
---

It says it fixes something. But:
1) It it retrieves menuitem if parentofparent, it should use it's parent command: (Sender as TMenuItem).Parent.Command.
2) All calls to InsertMenuItem (there is only 1) define menuinfo.hSubMenu := MenuHandle, which is always already created in CreateHandle. If I 'fix' item 1, it never gets to SetMenuItemInfo anymore, supporting this statement.

Any thoughts?

Micha.

I also got this already since late last week (wednesday or so)

Vincent Snijders wrote

Forwarded to the list.

Sorry for that. For some reason your messages to the list aren't modded so that 'Reply-To' is the list. Most of your messages have your own email address as reply to address. (Except this forwarded one, it seems). Strange.

Regards,

Micha.

Well, completing the interface implementation does make it all work. I have attached a patch for that. But: it has a gigantic memory leak. If I take the progressbar example and let it fire every 50ms, memory is depleted in 10 seconds. Not good.

Regards,

Micha.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00044.bin
Type: application/octet-stream
Size: 3569 bytes
Desc: "beginendpaint.patch"
Url : http://localhost/pipermail/lazarus/attachments/20030701/1c179f44/bin00044.bin

Forwarded to the list.

-----Oorspronkelijk bericht-----
Van: Micha Nelissen
Verzonden: dinsdag 1 juli 2003 15:25
Aan:

I found it! The BeginPaint function is not implemented in lcl/include/winapi.inc. Can we introduce a method for it in the interface?

Regards,

Micha.

Strange, I do not recieve such messages. Only when trying to execute lazarus, but the progressbar example works fine.

Micha.

Why do all buttons disappear, I can reason that the smooth button disappears because erasebackground redraws over it or something, but why do *all* of them disappear? IOW: If only 1 item needs to be redrawn, why are all?

and only every second a blue block is shown.

It's meant to be like this. By default, smooth is 'on', toggling smooth disables smooth, and thus 'blocky'.

I might have to do something with the changes to the code of wm_erasebackground recently.

Indeed.

Regards,

Micha.

ide.

Same here, but the progressbar example has a new bug: When you click on toggle smooth, all buttons disappear and only every second a blue block is shown. I might have to do something with the changes to the code of wm_erasebackground recently.

Vincent

Added.

Mattias

Did you try -gh?