Error when app is run from clients

[RollyS]

I don't get it at all. I installed my app on a server, and everything is fine when I run it there. But when I try to run it from the workstations, I see run time error. The error says that this so-and-so controls are not registered.

I find this really strange 'coz all controls are registered on the server after my installation. And I definitely see some controls (like command buttons and text boxes) on the MDI form when I run my app (from the workstations). But when I try to open those forms with SSTab, Crystal Report Control and MSHFlexGrid, there is an error.

Don't you find it strange? Why do the command buttons, and text boxes come out OK in the MDI form? Why not the SSTab and MSHFlexGrid? Aren't they controls too like command buttons and text boxes?

My purpose is for the clients to run the application from the server so that I only have to make one installation.

I really am perplexed. I know my app's packaging is perfect coz I tried it to several computers. Can somebody tell me what to do. I'd really appreciate it.

 

[JohnYingling]

The program is only loaded from the server but is running on the workstation and therefore VB looks for the controls using the workstation's Registry. The "standard" controls are contained in the VB6 runtime which is also running on the workstation. You must intall the App on each workstation. I don't know any way to run an App on a server but display on the workstation (but that does not mean there is not a way). Try

http://www.msdn.microsoft.com.

http://WWW.VBCompare.Com

 

[chiph]

Many people are using the Windows Terminal Services Client to run applications off a central server. In that case, registering the controls on the server would be all you needed.

Chip H.

 

[NipsMG]

NOTE!!!! If you decide to use the Package and Deployment wizard w/ a program using the Crystal Reports control, MAKE SURE that the file implode.dll is INCLUDED AS A DEPENDANCY.
(if you are using Crystal Reports 7 or Crystal Reports 8)


I have NO IDEA WHY this is a problem, but I had NUMEROUS problems getting my programs to work on another computer, and this was the solution that I found on the SeagateSoftware website.. and it worked correctly.


-- Just a heads-up

Michael P. Gerety

(also, depending on the version you're using, I'd download the newest craxdrt.dll from the SeagateSoftware website.

 

[dilettante]

RollyS,

These guys are all pretty much "right" - you have to INSTALL the client VB program on each workstation. There are really only a couple ways around this:

* Terminal Services or Citrix technology to make your "client" machines TERMINALS to programs (the client program, multiple copies) that actually run on the server! This is one flavor of "thin-client" computing. This isn't "free" from a developer's perspective - you have to make sure you follow the guidelines for your VB code to safely run under multiple users on the same server. Mostly a concurrency-management issue.

* Write a web application using ASP (Active Server Pages) or somesuch technique at the server. This is pretty "thin" as well, but can have some client-side script logic on the web pages. Doesn't have to be a complete rewrite, but more or less will be.

* Write a web application that relies on most of the logic of your client program being a Java applet or ActiveX object that the browser downloads and hosts. Certainly some rewriting (or entire rewrite for Java). If your client does much of anything on the local machine you're probably screwed unless... well this one can be complicated if you use Java.

* Wait for .NET, which is intended (among other things) to make client installation much easier and more transparent.

What you are bumping your head against here is the very thing which has been killing "fat client" client/server. For applications with a large user base most people have been moving toward ASP thin-client computing. For a complex application you need to break your client down into object classes that the script code in an ASP page can invoke - raw script can be too slow. And then there's the issue of session management. Well, let's just say it can be a lot of work if you're a VB programmer. ASP.NET will simplify this by replacing script pages with VB.

I know other people who are struggling trying to hold onto that old-fashioned fat-client VB approach by using Citrix (or Windows Terminal Services - Citrix was there first, but now their products are add-ons to Terminal Services). This turns out to be pretty dumb in most cases.

The Citrix/TS stuff gets rid of the deployment problem, but places a tremendous burden on the server. The bloated code application developers typically create today only really functions at all because of the assumption of a dedicated, resource-rich client PC. So now turn around and try running 100 or 1000 copies AT THE SERVER! Duh!

This approach was designed for rich-client apps you wanted to offer outside or other occasional users access to. Since avoiding the cost of deployment to large numbers of users is precisely what we're trying to accomplish here the Citrix/TS approach fails miserably.

Any other takes on this? I'm wide open to correction and suggestions.

 

[chiph]

dilettante -

No, you pretty much covered all the bases.

Chip H.

 

[HowNowBrownCow]

OK then, so explain this. I have run into a similar problem. I have developed an access app that uses activex controls. Throughout the organisation we have a mixture of people who have straight citrix (thin) clients and others who have access to citrix through windows.

The app works fine on the client machines that have windows installed but the thin clients fall to pieces (i get a run-time error) as soon as the following bit of code is included:

dim n as imagelist

Now. The imagelist is registered etc.etc. and the actual imagelist itself is being instantiated just fine, it is only when I try and dimension it through code that it falls apart...

Are you trying to tell me that my app is actually trying to reference the registry on the thin clients? That is just not possible - isn't it completely against the whole citrix concept? ie. all of the application processing is handled by the server and only the video and input/output are sent to the client... it really shouldn't matter what the client has in the registry...

I'm stumped...

 

[chiph]

I haven't used the straight Citrix clients, but I'm guessing that the Citrix software is trying to instantiate the imagelist for you on the client, whose version is not there, or is out-of-date.

Have you checked with Citrix on this?

Chip H.

 

[HowNowBrownCow]

I just left them a message. I will get back to you when I find out the results.

 

[rocken]

I'm having the same problems!! I have an Access datebase connected to a VB interface exe file. When I run it locally on my PC no problems! When I package and deploy it I get ado & comdlg errors during the install.

 

[NipsMG]

rocken-

I almost ALWAYS have gotten ADO errors on install.. It seems to be a problem with vp6sp3 P&D wizard. I've always had to ignore the error.

Just MAKE SURE that if you're installing on Win95 that the machine has DCOM installed FIRST, then install MDAC_TYP.exe (ADO).

After this you should be able to run the program without error, even if the P&D wizard gave you trouble.

--NipsMG