| View previous topic :: View next topic |
| Author |
Message |
JD
Guest
|
 Posted: Mon Jul 05, 2004 11:29 am Post subject: Hiding a published property |
 |
|
I have a component derived from TComponent and I want to hide
the Name property from the Object Inspector.
As I understand it, the correct approach is to assign the
property a NULL PropertEditor but I'm getting errors.
namespace Mycomponent
{
void __fastcall PACKAGE Register()
{
TComponentClass classes[1] = {__classid(TMyComponent)};
RegisterComponents("SomePallette", classes, 0);
TPropInfo *PropInfo = ::GetPropInfo( __typeinfo(TMyComponent), "Name" );
RegisterPropertyEditor( *(PropInfo->PropType), __classid(TMyComponent), "Name", NULL );
}
}
The initial error was Call to undefined function 'RegisterPropertyEditor'
so I added #include <DesignIntf.hpp> to the header and now I'm
getting 2 other linker errors:
[Linker Error] Unresolved external '__fastcall Designintf::RegisterPropertyEditor(Typinfo::TTypeInfo *, System::TMetaClass *, const System::AnsiString, System::TMetaClass *)' referenced from C:...xxx.OBJ
[Linker Fatal Error] Fatal: Could not open c:...xxx.bpl (program still running?)
I suspect that the second error is the result of the first
because the path that it referenced is not where the package
resides.
Could some one please tell me what I'm doing wrong here?
~ JD
|
|
| Back to top |
|
 |
OBones
Guest
|
| Posted: Mon Jul 05, 2004 11:30 am Post subject: Re: Hiding a published property |
|
|
You need to add DesignIde.bpi to the requires of your design time package.
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Mon Jul 05, 2004 7:31 pm Post subject: Re: Hiding a published property |
|
|
"JD" <nospam (AT) nospam (DOT) com> wrote
| Quote: | I have a component derived from TComponent and I
want to hide the Name property from the Object Inspector.
|
Why would you hide that property? The IDE needs that property in oder to
manage the form's header file correctly.
Gambit
|
|
| Back to top |
|
|
JD
Guest
|
| Posted: Mon Jul 05, 2004 9:15 pm Post subject: Re: Hiding a published property |
|
|
"Remy Lebeau (TeamB)" <gambit47.no.spam (AT) no (DOT) spam.yahoo.com> wrote:
| Quote: |
"JD" <nospam (AT) nospam (DOT) com> wrote in message
news:40e93b93$1 (AT) newsgroups (DOT) borland.com...
I have a component derived from TComponent and I
want to hide the Name property from the Object Inspector.
Why would you hide that property? The IDE needs that property in oder to
manage the form's header file correctly.
|
Since only one instance of the component is allowed in the
application, I wanted to prevent the user from changing the
name and set the default name to not have the appended numeric
character (which I haven't been able to do).
None of it's needed - just wanted to do it to see if I could.
However, my observation is that assigning a NULL property editor
only removed it from the Object Inspector. The property is still
there and the component still performs as expected - well not
completely but that's related to my other thread about only
the main form as owner. I'll post that when I've had more time
to look at it.
~ JD
|
|
| Back to top |
|
|
JD
Guest
|
| Posted: Mon Jul 05, 2004 9:16 pm Post subject: Re: Hiding a published property |
|
|
OBones <obones_ssspp (AT) gfgdf_altern (DOT) org> wrote:
| Quote: | You need to add DesignIde.bpi to the requires of your design time package.
|
That did it. Thanks.
~ JD
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Mon Jul 05, 2004 10:09 pm Post subject: Re: Hiding a published property |
|
|
"JD" <nospam (AT) nospam (DOT) com> wrote
| Quote: | Since only one instance of the component is allowed
in the application, I wanted to prevent the user from
changing the name
|
Simply hiding the property from the Object Inspector does not prevent the
property from being changable in general. The property itself still exists
in the actual component, and can still be accessed programmably.
Why do you think preventing the Name from being changed will prevent
multiple instances of your components? It won't.
| Quote: | and set the default name to not have the appended numeric
character (which I haven't been able to do).
|
What is wrong with having the default naming?
You are messing around with the IDE's behaviors for something that you are
taking a completely wrong approach for. There are better ways to prevent
multiple instances. In fact, I already gave you that code a few days ago.
Why did you chose not to use it?
Gambit
|
|
| Back to top |
|
|
Fishface
Guest
|
|
| Back to top |
|
|
JD
Guest
|
| Posted: Sat Jul 10, 2004 9:26 am Post subject: Re: Hiding a published property |
|
|
"Remy Lebeau (TeamB)" <gambit47.no.spam (AT) no (DOT) spam.yahoo.com> wrote:
| Quote: | [...] Why do you think preventing the Name from being
changed will prevent multiple instances of your components?
|
I don't. As I noted: "None of it's needed - just wanted to do
it to see if I could.".
| Quote: | What is wrong with having the default naming?
|
I just didn't want the numeric apendix. No other reason.
| Quote: | [...] In fact, I already gave you that code a few days ago.
Why did you chose not to use it?
|
I did and it works as expected (thank you) in respect to a
single instance but the part where it I want only the main
form as owner does not.
The problem is that at design time, the MainForm and the
Application->MainForm are not the same. I presume that the
compiler gets that distinction because when I had bad
logic in the component, it called Application->Terminate when
it was dropped on the form and the compiler was dumped from
memory as a result.
I could use some API to find it but it's a catch22. I need to
know something special about the main form and if I knew that,
I'd be able to get at it with the VCL.
I would think that there would be a way to know what the main
form is but I simply don't know how. I can't even think of a
possible senerio to test.
~ JD
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Sat Jul 10, 2004 7:55 pm Post subject: Re: Hiding a published property |
|
|
"JD" <nospam (AT) nospam (DOT) com> wrote
| Quote: | I just didn't want the numeric apendix. No other reason.
|
The TComponent::SetName() method is virtual, so just override it in your
component and change the new name value to what you want, then pass the
altered value to the base class for default handling.
| Quote: | I did and it works as expected (thank you) in respect to a
single instance but the part where it I want only the main
form as owner does not.
|
You need to be more specific. You should know by now that just saying it
doesn't work says nothing about the actual problem you are having with it.
| Quote: | I would think that there would be a way to know
what the main form is
|
There is only one way to know that - via the TApplication::MainForm
property. Being assigned to that property is the only thing that makes a
form be a MainForm in the first place. If the TApplication::MainForm
property is not doing what you need it to do, then you cannot do what you
need to do.
Gambit
|
|
| Back to top |
|
|
JD
Guest
|
| Posted: Sun Jul 11, 2004 5:57 am Post subject: Re: Hiding a published property |
|
|
"Remy Lebeau (TeamB)" <gambit47.no.spam (AT) no (DOT) spam.yahoo.com> wrote:
| Quote: | [...] You need to be more specific. You should know by now
that just saying it doesn't work says nothing about the
actual problem you are having with it.
|
I just re-read my post and it's clear (to me) that I did. The
following paragraph provided the reason it didn't work which
was that at design time, the Application->MainForm property
did not match the IDE's main form.
| Quote: | I would think that there would be a way to know
what the main form is
There is only one way to know that - via the TApplication::MainForm
property. Being assigned to that property is the only thing that makes a
form be a MainForm in the first place. If the TApplication::MainForm
property is not doing what you need it to do, then you cannot do what you
need to do.
|
I'm not ready to accept that yet. I'll try enumerating the
windows to see what I can see. Who knows (?) - maybe I'll get
lucky. Besides, if push comes to shove, I can always throw at
run time and force the programmer to move the component to the
main form.
~ JD
|
|
| Back to top |
|
|
JD
Guest
|
| Posted: Sun Jul 11, 2004 6:55 pm Post subject: Re: Hiding a published property |
|
|
"JD" <nospam (AT) nospam (DOT) com> wrote:
| Quote: | [...] I'm not ready to accept that yet.
|
I am now!!
~ JD
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Sun Jul 11, 2004 8:57 pm Post subject: Re: Hiding a published property |
|
|
"JD" <nospam (AT) nospam (DOT) com> wrote
| Quote: | I just re-read my post and it's clear (to me) that I did. The
following paragraph provided the reason it didn't work which
was that at design time, the Application->MainForm property
did not match the IDE's main form.
|
But you didn't say why it didn't match. Was it NULL? Was it set to another
form?
| Quote: | I'm not ready to accept that yet. I'll try enumerating
the windows to see what I can see.
|
That won't work. Again, there is no way to identify a MainForm without the
TApplication::MainForm property - period. That is the only identifier
available. Nothing is stored in the form that becomes a MainForm. You
can't rely on how the user chooses to name their MainForm.
| Quote: | Besides, if push comes to shove, I can always throw at run time
and force the programmer to move the component to the main form.
|
You may have to do exactly that. The only problem is that if the component
is already on the main form, it still may not know which form is the
MainForm since the TApplication::MainForm property is not assigned until
after the first form and its subcomponents are fully created. At the very
least, you could see if the component's Owner is a form, and if so then see
if the TApplication::MainForm is still NULL, meaning that the first form is
still in the process of being created. The only problem with that approach,
though, is that it is no guarantee that the form being created is going to
become the MainForm afterall. The user could be dynamically allocating the
form manually and not using TApplication::CreateForm() at all, which is the
only way the TApplication::MainForm property can be assigned.
Gambit
|
|
| Back to top |
|
|
JD
Guest
|
| Posted: Fri Jul 16, 2004 4:48 am Post subject: Re: Hiding a published property |
|
|
"Remy Lebeau (TeamB)" <gambit47.no.spam (AT) no (DOT) spam.yahoo.com> wrote:
| Quote: | [...] the TApplication::MainForm property is not assigned
until after the first form and its subcomponents are fully
created.
|
Pointing that out to me lead to a solution. I reasoned that if
I posted a message to the components owner (already confirmed
to be a TForm), that it wouldn't get processed until the form
was fully created. All I had to do was use SetWindowsHookEx
with the WH_GETMESSAGE flag and post a custom message to the
owner form.
Inside the GetMessageCallBackProc I test the Owner's handle
against the MainForm handle and it works like a charm.
~ JD
|
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Fri Jul 16, 2004 8:08 am Post subject: Re: Hiding a published property |
|
|
"JD" <nospam (AT) nospam (DOT) com> wrote
| Quote: | Pointing that out to me lead to a solution. I reasoned that
if I posted a message to the components owner (already
confirmed to be a TForm), that it wouldn't get processed
until the form was fully created. All I had to do was use
SetWindowsHookEx with the WH_GETMESSAGE flag
and post a custom message to the owner form.
|
You don't need the hook. You could just post the message back to the
component directly. If it doesn't already have an HWND that you can post
to, you can use AllocateHWnd() to create a temporary one.
Gambit
|
|
| Back to top |
|
|
JD
Guest
|
| Posted: Sat Jul 17, 2004 7:34 am Post subject: Re: Hiding a published property |
|
|
"Remy Lebeau (TeamB)" <gambit47.no.spam (AT) no (DOT) spam.yahoo.com> wrote:
| Quote: | You don't need the hook. You could just post the message
back to the component directly.
|
The component is derived from TComponent so I can't use WndProc.
| Quote: | If it doesn't already have an HWND that you can post to, you
can use AllocateHWnd() to create a temporary one.
|
Ok. I found the example in the help and it couldn't be more
simple to use. However, IIRC, windows resources has a limit on
the number of timers, correct (the example was taken from TTimer)?
Is AllocateHWnd the underlying reason? IOW, could I *possibly*
run into a system resource problem using AllocateHWnd?
Using the hook works as I'm sure AllocateHWnd will. I understand
that I need one hook for posted messages and another for sent
messages but other than consolidating the message processing,
is there any reason to use one method over the other or a
reason to not use one of them?
~ JD
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
