Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2003-06

Patch: progressbar smooth and vertical (win32)

11 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Micha Nelissen
to Michael Van Canneyt: A question. I have been testing this, and I always get an 'Invalid Class typecast' when I…
Michael Van Canneyt wrote 9 lines
On Thu, 26 Jun 2003, Micha Nelissen wrote: > As you can see, I have commented the BarShowText functionality, > because I can't get it to work. I think there is no functionality in > win32 natively to draw text on a progressbar. How is it supposed to > look? A question. I have been testing this, and I always get an 'Invalid Class typecast' when I try the quit menu. Do you have this too ?

I've found it. It happens right after the line I patched earlier; win32object.inc:542. Sender.Owner = nil there. Is there a difference for a TMenuItem between a parent and an owner? Shouldn't those both be simply Sender.Parent? (Or Sender.Owner)?

Regards,

Micha.

Reply by email

Michael Van Canneyt
to Micha Nelissen: Attached is a patch to recreate the progressbar control when the user wants to change…
Micha Nelissen wrote 8 lines
Hi, Attached is a patch to recreate the progressbar control when the user wants to change smooth or vertical. As you can see, I have commented the BarShowText functionality, because I can't get it to work. I think there is no functionality in win32 natively to draw text on a progressbar. How is it supposed to look?

A question. I have been testing this, and I always get an 'Invalid Class typecast' when I try the quit menu. Do you have this too ?

Michael.

Reply by email

Michael Van Canneyt
to Micha Nelissen: The first one is Sender.Parent for sure. But the second one: DrawMenuBar wants a handle…
Micha Nelissen wrote 24 lines
Micha Nelissen wrote: > Michael Van Canneyt wrote: >> On Thu, 26 Jun 2003, Micha Nelissen wrote: >> >>> As you can see, I have commented the BarShowText functionality, >>> because I can't get it to work. I think there is no functionality in >>> win32 natively to draw text on a progressbar. How is it supposed to >>> look? >> >> A question. I have been testing this, and I always get an 'Invalid >> Class typecast' when I try the quit menu. Do you have this too ? > > I've found it. It happens right after the line I patched earlier; > win32object.inc:542. Sender.Owner = nil there. Is there a difference > for a TMenuItem between a parent and an owner? Shouldn't those both > be simply Sender.Parent? (Or Sender.Owner)? The first one is Sender.Parent for sure. But the second one: DrawMenuBar wants a handle of the window of the menu which needs to be redrawn. Which often happens to be Sender.Owner. What guarantees me that Sender.Owner is a TWinControl? It could be a TComponent just as well....We're just lucky here that all menuitems on a form are owned by the form, but they could have been owned by a TButton just as well...no restriction there. How to get the form of the menu it's on? It could be a popup menu as well...

AFAIK, the owner should always be the form.

Michael.

Reply by email

Micha Nelissen
to Michael Van Canneyt: A question. I have been testing this, and I always get an 'Invalid Class typecast' when I…
Micha Nelissen wrote 15 lines
Michael Van Canneyt wrote: > On Thu, 26 Jun 2003, Micha Nelissen wrote: > >> As you can see, I have commented the BarShowText functionality, >> because I can't get it to work. I think there is no functionality in >> win32 natively to draw text on a progressbar. How is it supposed to >> look? > > A question. I have been testing this, and I always get an 'Invalid > Class typecast' when I try the quit menu. Do you have this too ? I've found it. It happens right after the line I patched earlier; win32object.inc:542. Sender.Owner = nil there. Is there a difference for a TMenuItem between a parent and an owner? Shouldn't those both be simply Sender.Parent? (Or Sender.Owner)?

The first one is Sender.Parent for sure. But the second one: DrawMenuBar wants a handle of the window of the menu which needs to be redrawn. Which often happens to be Sender.Owner. What guarantees me that Sender.Owner is a TWinControl? It could be a TComponent just as well....We're just lucky here that all menuitems on a form are owned by the form, but they could have been owned by a TButton just as well...no restriction there. How to get the form of the menu it's on? It could be a popup menu as well...

Regards,

Micha.

Reply by email

Michael Van Canneyt
to Micha Nelissen: If I may ask, why? The owner is only responsible for memory management, in delphi at…
Micha Nelissen wrote 20 lines
Michael Van Canneyt wrote: > On Thu, 26 Jun 2003, Micha Nelissen wrote: > >> The first one is Sender.Parent for sure. But the second one: >> DrawMenuBar wants a handle of the window of the menu which needs to >> be redrawn. Which often happens to be Sender.Owner. What guarantees >> me that Sender.Owner is a TWinControl? It could be a TComponent just >> as well....We're just lucky here that all menuitems on a form are >> owned by the form, but they could have been owned by a TButton just >> as well...no restriction there. How to get the form of the menu it's >> on? It could be a popup menu as well... > > AFAIK, the owner should always be the form. If I may ask, why? The owner is only responsible for memory management, in delphi at least, is this different for the lcl? I don't know what prevents me from writing in TForm1: Button1 := TButton1.Create(Self) MenuItem1 := TMenuItem.Create(Button1);

Yes, this is of course possible.

But the streaming mechanism creates all components with the form as the owner...

Michael.

Reply by email

Mattias Gaertner
to Micha Nelissen: If I may ask, why? The owner is only responsible for memory management, in delphi at…
Show quoted text 29 lines
On Thu, 26 Jun 2003, Micha Nelissen wrote: > Michael Van Canneyt wrote: > > On Thu, 26 Jun 2003, Micha Nelissen wrote: > > > >> The first one is Sender.Parent for sure. But the second one: > >> DrawMenuBar wants a handle of the window of the menu which needs to > >> be redrawn. Which often happens to be Sender.Owner. What guarantees > >> me that Sender.Owner is a TWinControl? It could be a TComponent just > >> as well....We're just lucky here that all menuitems on a form are > >> owned by the form, but they could have been owned by a TButton just > >> as well...no restriction there. How to get the form of the menu it's > >> on? It could be a popup menu as well... > > > > AFAIK, the owner should always be the form. > > If I may ask, why? The owner is only responsible for memory management, > in delphi at least, is this different for the lcl? I don't know what > prevents me from writing in TForm1: > > Button1 := TButton1.Create(Self) > MenuItem1 := TMenuItem.Create(Button1); Yes, this is of course possible. But the streaming mechanism creates all components with the form as the owner...

Only the designed components. But components can create child components. e.g. TRadioGroup.
Use TMenu.Parent for the parent component. Check if it is a TWinControl. If not, then write a warning, that this kind of component is unsupported and continue.

Mattias

Reply by email

Micha Nelissen
to Michael Van Canneyt: A question. I have been testing this, and I always get an 'Invalid Class typecast' when I…

Hi,

Michael Van Canneyt wrote 12 lines
On Thu, 26 Jun 2003, Micha Nelissen wrote: > Attached is a patch to recreate the progressbar control when the > user wants to change smooth or vertical. > > As you can see, I have commented the BarShowText functionality, > because I can't get it to work. I think there is no functionality in > win32 natively to draw text on a progressbar. How is it supposed to > look? A question. I have been testing this, and I always get an 'Invalid Class typecast' when I try the quit menu. Do you have this too ?

Yes. That's why I asked how to trace exceptions... :).

Regards,

Micha.

Reply by email

Micha Nelissen
to Michael Van Canneyt: AFAIK, the owner should always be the form. Michael.
Michael Van Canneyt wrote 12 lines
On Thu, 26 Jun 2003, Micha Nelissen wrote: > The first one is Sender.Parent for sure. But the second one: > DrawMenuBar wants a handle of the window of the menu which needs to > be redrawn. Which often happens to be Sender.Owner. What guarantees > me that Sender.Owner is a TWinControl? It could be a TComponent just > as well....We're just lucky here that all menuitems on a form are > owned by the form, but they could have been owned by a TButton just > as well...no restriction there. How to get the form of the menu it's > on? It could be a popup menu as well... AFAIK, the owner should always be the form.

If I may ask, why? The owner is only responsible for memory management, in delphi at least, is this different for the lcl? I don't know what prevents me from writing in TForm1:

Button1 := TButton1.Create(Self)
MenuItem1 := TMenuItem.Create(Button1);

? Maybe not the convention, but I could imagine scenario's where one may group components (for memory management) under a different component than a form.

Micha.

Reply by email

Mattias Gaertner
to Micha Nelissen: Attached is a patch to recreate the progressbar control when the user wants to change…
Hi, Attached is a patch to recreate the progressbar control when the user wants to change smooth or vertical.

Applied.

Mattias

As you can see, I have commented the BarShowText functionality, because I can't get it to work. I think there is no functionality in win32 natively to draw text on a progressbar. How is it supposed to look?

A centered text. In its current implementation in the gtk interface it is too gtk specific. So, just skip this property for now and try more important things.
Is TTimer now working under win32?

Mattias

Reply by email

Micha Nelissen
to Micha Nelissen: Attached is a patch to recreate the progressbar control when the user wants to change…
Mattias Gaertner wrote 13 lines
On Thu, 26 Jun 2003 15:12:00 +0200 "Micha Nelissen" wrote: > As you can see, I have commented the BarShowText functionality, > because I can't get it to work. I think there is no functionality in > win32 natively to draw text on a progressbar. How is it supposed to > look? A centered text. In its current implementation in the gtk interface it is too gtk specific. So, just skip this property for now and try more important things. Is TTimer now working under win32?

Okay. TTimer works correctly now, I've tested interval changes, starting, stopping, that all works.

Regards,

Micha.

Reply by email

Micha Nelissen

Hi,

Attached is a patch to recreate the progressbar control when the user wants to change smooth or vertical.

As you can see, I have commented the BarShowText functionality, because I can't get it to work. I think there is no functionality in win32 natively to draw text on a progressbar. How is it supposed to look?

Regards,

Micha.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00035.bin
Type: application/octet-stream
Size: 2482 bytes
Desc: "progressbar_smooth_vert.patch"
Url : http://localhost/pipermail/lazarus/attachments/20030626/f51c5b93/bin00035.bin

Reply by email