Common Program 4

[RebelFox]

I have a set of programs that all access a DB2 server ( AS400 ). In each program I end up coding an identical login form that accepts a username and password which is then validated against the DB2 user profile database.

I think I should create this login as a stand alone program that I can call from each of my projects. The program just
needs to return a 'valid user' or 'invalid user' value.

I could set up a Class Module and copy it into each program but can Class Modules have forms in them?
Is there a way of creating the effect of a class module instance with a form as a common program so I can use my
common login program like this?

Sub Proc MyProject

'
' Call logon method in DB2Server program to display
' a form, accept a usename textbox, accept a password
' textbox and validate it against the AS400 before
' returning a booleanvalue of True or False.
'
blnLoggedOn = DB2Server.LogOn ' Program & Method

'
' If Valid UserName & Password
If ReturnCode = True Then
.
. Do Processing
.
Endif

End Proc

 

[rsinj]

Use WinAPI and look up examples using CreateWindow to create the window dynamically.

 

[fredericofonseca]

go to

http://www.mvps.org/vb/samples.htm

and look at AniCtrl.zip and hello.zip

Both use createwindow and are therefore a good start for you.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[mattKnight]

Is there a way of creating the effect of a class module instance with a form as a common program so I can use my
common login program like this?

What about an active-X dll or exe. You can have forms in each type.

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[RebelFox]

Mattknight:-

how do I call the exe option synchronusly?
The only way I know how to call another exe is via a shell command.

 

[mattKnight]

The activeX exe is com object and can be (slighlty simplisticly) viewed as a class object that exists in its own process space. Calls to it are synchronous (i.e. the calling program waits for the active x call to complete)

You would call the active x somewhat similar to this

dim myLoginForm as LoginForm
dim blnValid as boolean

set myloginForm = new LoginForm

blnValid = myLoginForm.Login

To build one, select either active x dll or exe from the new project menu.



Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[ArtieChoke]

I would go with the ActiveX dll approach. Create the class with the login form in the dll. Then include it in all your programs. Simple and effective.

You'll need to register it on each client machine the program runs on.

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[Skittle]

This is similar to something I am trying to understand.

What is the difference between an ActiveX exe and and
ActiveX dll?

Dazed and confused

 

[mmilan]

As previously stated, an Active X exe has it's own process space, with it's own resources. Essentially, the operating system treats it as a distinct new program in it's own right, with all the trappings.

An ActiveX DLL on the otherhand gets run within the process space of the calling program.

mmilan.

 

[Skittle]

Don't really see what difference it makes to a layman.
The flow of the two calls is effectively the same in that
the calling program will wait for the called ActiveX to finish ( i.e. both methods are synchronous ).

The benefits or disadvantages of one way or the other seem to just be the way the ActiveX is stored. OK so there is some issue about a sperate program space but under what circumstances is that important?

Dazed and confused

 

[mmilan]

Probably not these...

I merely responded to a direct question as to what the differences were.

mmilan

 

[ArtieChoke]

Using an ActiveX exe will take a large performance hit because it is outside of the program's address space and the data must be sent to the object via a process called marshalling. If you are making a lot of calls to a class, it will make your program go very sloooooooooooowly!


"I think we're all Bozos on this bus!" - Firesign Theatre

 

[RebelFox]

I have one query left.

I can see how an ActiveX DLL is the best way to store the program so that its run efficiently. The only thing I am not sure about is the program flow.

Consider program A will use the .DLL Active X program called MyActiveX:-

I can create a .DLL exe consisting of a module and a
form. The module will show the form to accept input ( i.e. form1.show ) in a procedure called GetInput.


When program A calls the procedure ( MyActiveX.GetInput )
the form is displayed in the procedure but the program flow returns to program A. This means I havn'tcalled a program that accepts a username and password, validates it and returns 'true or 'false'. It means I have a program that displays a form and it is virtually seperate from the calling program ( i.e. modal can't be set to make MyActiveX top and if a username and password is entered in the form, how does it pass back the values to program A).

Sorry if this is a dumb question. I am new to this type of programming.
I want to use the ActiveX .DLL,
the form will be displayed BUT the

 

[ArtieChoke]

You can display the form as modal from the class. Then when all inputs have been verified, and the form is unloaded, the next line in the routine that displayed the form will execute. You could have that routine return a status value indicating the login is okay, not okay or the user canceled. Then add properties in the class that you can call to get the user id if you need it.


"I think we're all Bozos on this bus!" - Firesign Theatre

 

[rsinj]

I still believe that in this case, you are better off including the API calls to CreateWindow, etc. in your class to do this.

If you go with the ActiveX DLL, it is a separate distributed/managed/registered/maintained module that you need to be concerned with. Additionally, when you distribute any of your applications which require the common login form, you will have to include the ActiveX DLL - to be sure it is on the user's machine.

With the few calls to CreateWindow, you are reusing/including your class in each application. Each application is then a self-contained unit which has one less dependency an externally written component that you need to provide.

Additionally, this will get you even better performance than the ActiveX DLL.

 

[mmilan]

Artie - Cheers, didn't know that, do now...

 

[ArtieChoke]

It's the ole many ways to skin a program time here!

If this routine is used in 20 programs and a bug is found or mod required - 20 recompiles - doh! Putting a dll file on a client machine is not a big deal - you can even automate it within the program. Depending on the complexity of the program, there most likely will be other VB dll files needed as well.

It all depends on your needs and what you're willing to go through when a change is necessary.

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[RebelFox]

ArtieChoke

Many thanks I followed your method and it works well.

Rsinj

I din't go with your method because I didn't feel confident enougth I understood the code. I've done lots of green screen programming, but VB is still a bit alien to me. er I do see your point though.
I'm not concearned to much about response speed but the fact that the windows API's are always going to be on each PC, regardless of the DLL factor is a strong selling point.

So this leads me to a follow up question....

In the real world of VB programming, how many of you guys use windows API's? My understanding from the books I've been reading is that you use API's when you want to do something you can't do with VB as it stands or if you need a really swift response. Is this correct or is it just different strokes for different folks?

 

[ArtieChoke]

Glad I could hep!

...is that you use API's when you want to do something you can't do with VB as it stands or if you need a really swift response...

That's my philosophy with VB. Also, it allows other less knowledgeable programmers (in terms of the API) to maintain the code. With our current speedy processors, putting up a form 3 milliseconds faster is not really a concern!

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[strongm]

>how many of you guys use windows API's

I've been known to on occassion...