Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 10 of 10 total |
Scope Again |
Sun, Sep 13 2015 6:53 AM | Permanent Link |
squiffy Telemix Ltd. | Having a problem I just can't see the cause of.
In the calling unit I have : procedure blah; var tempInstance: TForm; begin tempInstance:=TmyOwnForm.Create(nil); tempInstance.myProcInMyForm; // Problem line. tempInstance.Show; end; In the myOwnForm unit I have : type TmyOwnForm = class(TForm) ...usual stuff... public procedure myProcInMyForm; .... end; And the proc is defined in the implementation : procedure TmyOwnForm.myProcInForm; ...code... The form gets instantiated as I can show it just fine, but when I insert the "problem line" above it cannot see the procedure in the new form (says no proc/func matches).. It's declared in the interface section (I've tried in both the form class definition, in the public & private sections, and I've tried outside of the form definition. I have the new form unit in the uses bit. Surely if the form gets created I should be able to call a proc defined there? I'm obviously wrong but I just can;t see where. |
Sun, Sep 13 2015 7:04 AM | Permanent Link |
squiffy Telemix Ltd. | Ok, I have to declare tempInstance as the specific form type. TForm is no good.
Compiles now. Why is that? I thought that if it's a TForm type and I set it to a new creation of my specific form type, that would be correct. I can see that it isn't, but I don't get why. |
Sun, Sep 13 2015 7:14 AM | Permanent Link |
squiffy Telemix Ltd. | Sorry, it's obvious really.
My variable can only reference the TForm methods at compile time as that's what it's defined as. It obviously doesn't know about the extra bits in my form class unless the variable is declared as that class type. I'm guessing that were the compiler to ignore that it would probably run ok. 'Spose it's a bit much to ask for the compiler to work all that out from the Create line. My method doesn't work, but that's another issue... |
Sun, Sep 13 2015 9:06 AM | Permanent Link |
Raul Team Elevate | On 9/13/2015 6:53 AM, squiffy wrote:
> tempInstance:=TmyOwnForm.Create(nil); > tempInstance.myProcInMyForm; // Problem line. use: TmyOwnForm(tempInstance).myProcInMyForm; Raul |
Sun, Sep 13 2015 6:33 PM | Permanent Link |
Steve Gill | Unless I'm misunderstanding what you're saying, this should work fine as long as MyProcInMyForm is Public (which it is):
procedure blah; var tempInstance: TmyOwnForm; begin tempInstance:=TmyOwnForm.Create(nil); tempInstance.myProcInMyForm; tempInstance.Show; end; |
Sun, Sep 13 2015 11:48 PM | Permanent Link |
Raul Team Elevate | On 9/13/2015 6:33 PM, Steve Gill wrote:
> Unless I'm misunderstanding what you're saying, this should work fine as long as MyProcInMyForm is Public (which it is): > tempInstance: TmyOwnForm; OP defined the variable as "TForm" (not TmyOwnForm) so you'd need to cast it. Using the actual form class like your example would work as well but of course is a different declaration. The actual question was why did the compiler not "figure it out" (defined as TForm but created as TmyOwnForm). This is actually the benefit of the strong typing in EWB - it will catch this type of mistakes and not allow it (unless you override it by casting). Raul |
Mon, Sep 14 2015 4:26 AM | Permanent Link |
squiffy Telemix Ltd. | Yeah I realise that my code was the dodgy bit there.
My original post was made when I just couldn't see what was happening. I totally understand now why it doesn't (and shouldn't). |
Mon, Sep 14 2015 5:40 AM | Permanent Link |
Steve Gill | Hi Raul
<< OP defined the variable as "TForm" (not TmyOwnForm) so you'd need to cast it. Using the actual form class like your example would work as well but of course is a different declaration. The actual question was why did the compiler not "figure it out" (defined as TForm but created as TmyOwnForm). This is actually the benefit of the strong typing in EWB - it will catch this type of mistakes and not allow it (unless you override it by casting). >> I was actually responding to Squiffy's post. I didn't even see your post until I had posted my response. = Steve |
Mon, Sep 14 2015 7:28 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << 'Spose it's a bit much to ask for the compiler to work all that out from the Create line. >>
It's never the simple case that's the problem, it's something like this: var MyForm: TForm; begin MyForm:=TMyForm.Create(nil); MyForm.DoMyProcedure; MyForm:=SomeOtherTForm; MyForm.DoMyProcedure; end; IOW, there's no way for the *compiler* to figure this all out. It would have to be runtime code, and then we're getting into dynamic languages in ways that we're trying to avoid by using a compiler. Tim Young Elevate Software www.elevatesoft.com |
Mon, Sep 14 2015 8:33 AM | Permanent Link |
Raul Team Elevate | On 9/14/2015 5:40 AM, Steve Gill wrote:
> I was actually responding to Squiffy's post. I didn't even see your post until I had posted my response. You did ended up responding to my post though hence my reply. Raul |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |