Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 16 total
Thread Cannot access the ... instance member from within a class method
Tue, Jul 4 2017 5:28 PMPermanent Link

Big Al

Ok, so I have a MainForm TMainForm, and a Login form TFormLogin.

From a menu item, I open the Login Form modally.
In the ButtonClick I want to execute a procedure that's in TMainForm called VerifyLogin

So in the ButtonClick of the login form I have

TMainForm.VerifyLogin('XXX');

In my MainForm, I have in public
   Procedure VerifyLogin (password: string);

and towards the end of my MainForm I have

procedure TMainForm.VerifyLogin(pswd: string);
begin
end;

I don't do anything yet, but need to stop the compile error

When compiling I get the following error:

[Error] login.wbs (56,14): Cannot access the VerifyLogin('xxx') instance member from within a class method


Again, probably something dumb I'm doing and I wait until I've spent at least 3 hours on the issue before throwing my hands up and asking for help, so here I am again.

Thanks for any help you all can give.

Big Al
Tue, Jul 4 2017 5:48 PMPermanent Link

Mark Brooks

Slikware

Avatar

You need to reference the form variable not the class
Tue, Jul 4 2017 5:53 PMPermanent Link

Big Al

>Mark Brooks wrote:

>You need to reference the form variable not the class

Mark, I'm sorry, I am sure you're right, but I don't understand what I would need to change to make it work.

Big Al
Tue, Jul 4 2017 6:18 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 7/4/2017 5:28 PM, Big Al wrote:
> Ok, so I have a MainForm TMainForm, and a Login form TFormLogin.
>  From a menu item, I open the Login Form modally.
> In the ButtonClick I want to execute a procedure that's in TMainForm called VerifyLogin
>
> So in the ButtonClick of the login form I have
>
> TMainForm.VerifyLogin('XXX');

Al,

You cannot call like this - this (TMainForm) is a declaration of the
class and not an actual instance of the class.

EWB by default also creates an instance variable for the form

It's right at the end of the interface section and would be something
like this

var
  frmMainForm:TMainForm;

or similar.


Assuming EWB auto-creates all what you need to do instead is to call

frmMainForm.VerifyLogin('XXX');

for this to work your login form also needs to include mainform in its
uses clause

so in login form you should have

....
implementation
  uses MainForm;
....
//in your buttonclick event
frmMainForm.VerifyLogin('XXX');


Raul
Tue, Jul 4 2017 6:35 PMPermanent Link

Big Al

Raul wrote:

>frmMainForm.VerifyLogin('XXX');

>for this to work your login form also needs to include mainform in its
>uses clause

Raul,
Thanks for the explanation. That worked perfectly.

I don't come from a Delphi/Pascal background so a lot of this should be easier than it is, but I'm making good progress and learning as I go.

This forum has been a tremendous help.

Thanks again everyone.

Big Al
Tue, Jul 4 2017 7:21 PMPermanent Link

Big Al

That worked, however still have a challenge or two.

I am wondering if an answer that Uil gave on a previous post is part of what I'm seeing.

When I do my MainForm.VerifyLogin, it runs and gets some data from my webservice and then loads some JSON data into a Public variable in MainForm. I can put a showmessage in the RequestComplete and see the data.

However  right after I run the MainForm.VerifyLogin procedure in my Login form, I do a showmessage and the data in the Public variable doesn't appear to be there.

Is that because the login script kept executing while the webservice was running? If so, what's the best way to deal with that. I could see setting some sort of variable when the VerifyLogin gets ready to run and then somehow check in my login form when that variable is changed in the RequestComplete?? Is that a reasonable way to do it? or is there a better way like an event I could hook or trap?

Big Al
Tue, Jul 4 2017 9:36 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 7/4/2017 7:21 PM, Big Al wrote:
> When I do my MainForm.VerifyLogin, it runs and gets some data from my webservice and then loads some JSON data into a Public variable in MainForm. I can put a showmessage in the RequestComplete and see the data.
>
> However  right after I run the MainForm.VerifyLogin procedure in my Login form, I do a showmessage and the data in the Public variable doesn't appear to be there.
>
> Is that because the login script kept executing while the webservice was running? If so, what's the best way to deal with that. I could see setting some sort of variable when the VerifyLogin gets ready to run and then somehow check in my login form when that variable is changed in the RequestComplete?? Is that a reasonable way to do it? or is there a better way like an event I could hook or trap?

Yes - EWB (or more specifically javascript in the browser) is
asynchronous - your VerifyLogin runs and returns control (i.e. it is not
blocking). Showmessage then runs and (correctly) shows nothing since the
webservice has not returned yet.

Once the Requestcomplete runs only is your data available (or error code
if it failed).

What you're proposing with the variable is basically called polling -
you'd run a timer that executes every say 200 msec or such and checks
variable.

It's wasteful in terms of resources but more importantly becomes
difficult to manage as app gets more complex.

I suggest You should very much be thinking in terms of callback
functions/events - this is basically what requestcomplete is.

You can define your own callbacks or in this case if you just have 2
forms you can split the logic up:

1. login form calls MainForm.VerifyLogin
2. once the web request completes it calls back into loginform function
-say "VerifyLoginComplete" at which point you can check the result and
then take appropriate action.

To take this a step further you can create your own app notifications -
see for example this post for ideas and discussion
(https://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&page=1&msg=12790#12790)


Raul
Wed, Jul 5 2017 6:58 AMPermanent Link

Big Al

>Raul wrote:


>I suggest You should very much be thinking in terms of callback
>functions/events - this is basically what requestcomplete is.

>You can define your own callbacks or in this case if you just have 2
>forms you can split the logic up:

>1. login form calls MainForm.VerifyLogin
>2. once the web request completes it calls back into loginform function
>-say "VerifyLoginComplete" at which point you can check the result and
>then take appropriate action.

>To take this a step further you can create your own app notifications -
>see for example this post for ideas and discussion
>(https://www.elevatesoft.com/forums??action=view&category=ewb&id=ewb_general&page=1&msg=12790#12790)

Thanks Raul, I'll take a look at what your suggesting and see what I can do.

Uli, sorry for mistyping your name in previous post.

Big Al
Wed, Jul 5 2017 7:21 AMPermanent Link

Big Al


>Raul wrote:


>I suggest You should very much be thinking in terms of callback
>functions/events - this is basically what requestcomplete is.

>You can define your own callbacks or in this case if you just have 2
>forms you can split the logic up:

>1. login form calls MainForm.VerifyLogin
>2. once the web request completes it calls back into loginform function
>-say "VerifyLoginComplete" at which point you can check the result and
>then take appropriate action.

>To take this a step further you can create your own app notifications -
>see for example this post for ideas and discussion
>(https://www.elevatesoft.com/forums??action=view&category=ewb&id=ewb_general&page=1&msg=12790#12790)

I learn best from examples, and of course the first time you do something is the hardest.

I am not sure I understand Matt's notes or Tim's but I will try my best. If I can't figure it out,  I may try timers for now.

Thanks again,
Big Al
Wed, Jul 5 2017 7:29 AMPermanent Link

Matthew Jones

Big Al wrote:

> I may try timers for now.

Take the time to learn the callbacks - it will save you a lot of hassle. Timers have their place, but not here.

--

Matthew Jones
Page 1 of 2Next Page
Jump to Page:  1 2
Image