ShellExecute Solution For You!! 2

[CCLINT]

Ever consider using an OLE container control?

Very simple to use and you can define the class to open the file with, and have the file open and edit right with-in your VB form, as if it was part of your application, using the define class, and combining the menue and toolbar of the class app with your VB Form,or open it in a seperate window using a compatible application...

 

[Hypetia]

Yes, I think it is a better solution to the problem we are discussing.

 

[MrVB50au]

OLE?

Ok, so you're saying that ActiveX controls only rely on VB to work, does this mean that an application built soly on ActiveX components will be rended useless? Are you also saying that (and, correct me if I'm wrong) A developer developing his application using any ActiveX control in his programming that it will not work in Win98 or WinXP when the user installs his application on their machine?

Hypetia quotes:
A program containing API calls will run on a fresh Windows 98 or Me without requiring VB whereas one that uses ActiveX controls will not run on Windows 98 because Win98 does not contain ActiveX controls. They are installed with Visual Basic.

 

[Hypetia]

I think you misinterpreted my words. I meant to say that if you write a program using ActiveX controls than you have to copy/install those ActiveX controls on every target machine that is about to host your program.

Say you want to use a status bar in your application.
There are two ways to incorporate a status bar in your application.
1. Use Microsoft Windows Common Controls ActiveX component.
2. Create a status bar of your own using CreateStatusWindow API function.

In first case you have to deploy the common controls ocx file (comctl32.ocx) on every target machine on which your program is going to run. Only copying your .exe file and running it on other computer will not work, until unless the required ActiveX components are already installed on that machine, which is not necessary.
Note that the size of this ocx file is about 600KB whereas that of your own program file might be less than 100KB. The advantage we get with this method is that programming and implementation is very easy.

As a second option if you make use of APIs to create status bar than these additional .ocx files are not required. The only dependency your application requires is the Visual Basic runtime library (msvbvm50.dll or msvbvm60.dll) which is an integral part of Windows 98 and all subsequent editions of Windows OS.

It means that you need just the .exe file of your program and it will work. No additional components required.
Your program will work even on a newly installed Windows 98 or XP machine without requiring Visual Basic or any ActiveX components. The payback is that advanced programming practices are required.

If you use ActiveX control, than you have to make sure that your installation package also installs the required ActiveX controls on the target machine.

We cannot assume that these components are already installed on the other computer and we have to keep them in the installation package anyway, consequently resulting in a LARGER setup package.

In the end I want to make it clear that I am not discouraging the use of ActiveX controls. I will again repeat that both approaches have their advantages and disadvantages as we discussed above and the choice is entirely yours.

 

[MrVB50au]

Okie Dokie,

That's what I thought, cause when I created an application for a business back in 2000, a Telemarking application, I did need to add the ocx's and appropiate dependancy files.

Thanks for clearing that up for me. I thought I was going crasy with confusion hahaha... I hope you didn't get offended by misunderstanding what you said... wasn't tended.

Now, I don't know stuff all about API's, I have heard of them but until yesterday I havn't had to do anything with it.

If I begin programming using API's can I create complete applications by using only API's and so I wouldn't get into trouble like the difference between Win98 and WinXP, how will I know which OS has what and which hasn't?

 

[Hypetia]

All editions of Windows OS support the most common set of APIs which we use mostly in a typical application.

The difference lies in its implementation - which may be slightly different in Windows 98 or XP. The correct implementation of the API should be decided after determining the current OS.
The current OS is determined, once again using an API function GetVersionEx. After the OS is determined, you should call the appropriate version of the API you are concerned. (like the example of GetOpenFileName function we discussed earlier)

 

[MrVB50au]

So then with one of my other applications I use:

Public MyAgent As IAgentCtlCharacterEx for a Microsoft Agent. Is then the IAgentCtlCharacterEx also an API? And if so, which one of windows DLL files would contain it, or, shouldn't I need to worry too much about that and just accept that these functions do this and that when calling API's?

 

[Hypetia]

I think using MS Agent this way is all right. Although I am not sure but I think that Microsoft has built the MS Agent interface around COM technology and applications normally access them this way as you are doing.

Moreover, even if an API interface exists for accessing MS Agent, I was not concerned about that because I was talking about most common set of APIs, which we use mostly in a typical application, which typically belongs to Win32 API.

MS Agent API, if one exists, is a special API and exempted from this most common set of APIs list.

 

[MrVB50au]

Thanks, I just wanted to know.

Thanks for all your help with understanding API's and my application. Now, Thanks to you, I know a little more on what I need to lookout for and what to do when calling a function from API's

Thanks again and if I could ever be an assistant in someway please feel free to ask.

Also, to give you a rundown on what I'm creating at this end, I've been in the making of an application for the last 2 years and tho' I have come up to a brick wall at times (eg: like the Shell command), it's been fun.

The application consists of a Main MDI app' that has these children: 'Data Entry Form', 'Grid Entry Form', 'Envelopes', 'Business Letters', 'Business Cards', 'Labels', and 'Resumes'.

The funcion for which I needed to get the 'Shell' function to work for was so the user can change the 'Business Card' by simply clicking on the [Edit Card] button which will take the currently displayed card (bitmap file) to MSPaint. What I ment by 'current' is that the path NOT THE FILE, is stored into a DB the user can 'Add' or/and 'Delete' cards from the list. They can also open an existing card create a completely new one in MSPaint and then save it as another file name. Then Add that new card to the current list. It's working great and the user isn't just limited to bmp files but can also use jpg's as well. The user of the application may have lot's of customers, so he/she needs to record their details into a DB file. When a customers' details is currently displayed, and the card has been selected, the user clicks on the [Create Card] button and is able to view and print as many copies of the cards as they wish.

Just thought I'd share a fraction of the app' with you and whoever else is reading this...hahaha!