Microsoft KB Archive/158264

INFO: FAQ on Developing with the ActiveX SDK ID: Q158264 The information in this article applies to: Microsoft ActiveX SDK, version 1.0 SUMMARY This article covers some of the most Frequently Asked Questions (FAQ) about developing with the Microsoft ActiveX SDK. You can find this and other FAQ articles by querying on the keyword "FAQ." MORE INFORMATION This FAQ is also available on the Microsoft Web site at http://www.microsoft.com/support/products/developer/activexsdk/content/faq Due to the increasing number of FAQ's on the ActiveX SDK, the FAQ's are categorized in the following manner: ActiveX Controls: Common questions associated with developing ActiveX controls for the Internet using the ActiveX SDK. ActiveX Documents: Issues relating to DocObject servers that can be hosted from various containers such as Internet Explorer WebBrowser Control: Top issues that focus on the WebBrowser control, including printing, redistribution, and hosting issues. Code Download: Closely tied with ActiveX Controls, these issues focus mainly on downloading components over the Internet. Internet Explorer Object Model: Issues related to the Object Model exposed by Internet Explorer are addressed here. WinInet: A wide range of issues relating to the WinInet APIs. Related FAQ's: "Where can I learn more about . . .?" type of questions are addressed here. Frequently Asked Questions on ActiveX Controls Q. What really is the difference between an OLE Control and an ActiveX control? A. ActiveX controls are a superset of OLE Controls. Originally, OLE Controls were required to support a number of interfaces that are optional for ActiveX controls. For ActiveX controls, the only requirements are that the control supports IUnknown and is self- registering (that is, exports DllRegisterServer and DllUnregisterServer). Mike McKeown addresses this very confused issue of OLE Controls versus ActiveX controls in the October 1996 issue of the MIND (Microsoft Internet Developer) magazine. More information on enabling controls for the Internet, as well as various documentation on interfaces and functions an ActiveX control should support, can be found on the "ActiveX Controls" section of the ActiveX SDK online documentation. Q. So, are out of the box OCXs, such as the one shipped with Visual Basic 4.0, also ActiveX controls? A. Yes. All OCXs are ActiveX controls. Q. How about MFC controls, are they also ActiveX controls? A. Yes, all MFC controls are ActiveX controls. An old Visual C++ 4.0 control is an ActiveX control, as is one created with Visual Basic 4.0 or the ActiveX controls BaseCtl Framework that comes as part of the ActiveX SDK samples. Look at the term ActiveX control as a renaming and restructuring of the OLE Control technology--an evolution. A control can be designed to work efficiently on the Internet, or to be hosted in desktop container applications, or to do both. Sure, some controls are not as well suited to be used on the Internet due to their large size and synchronously loading of properties, but they are still ActiveX controls. This is what causes most of the confusion. Q. Are there different types of ActiveX controls? A. Yes. The OLE Control and Control Container Guidelines version 2.0 describe a number of optional features that may be implemented. Some controls implement features that require corresponding features in the container in order to work properly. Conversely, some containers recognize only controls that implement some optional features. Older containers typically recognize only controls that are marked in the registry with the "Control" key and that implement the older OLE Control specification, although they may be able to use newer controls as Automation objects. Newer controls and containers can use something called "Component Categories" to describe their abilities and requirements. Component Categories are defined in the OLE Programmer's Guide, which is part of the ActiveX SDK and Win32 SDK. The OLE Control and Control Container Guidelines version 2.0 and other related specifications can be found under the InetSDK\Specs folder of the ActiveX SDK installation. Q. So, do all ActiveX controls work with Visual Basic 4.0? A. Most ActiveX controls should work with Visual Basic 4.0. It is possible that a control requires container support that Visual Basic 4.0 does not provide. This is true for any control and container combination. Q. Do all ActiveX controls work with Internet Explorer 3.0? A. Again, it is possible that controls require container support that Internet Explorer 3.0 does not provide. Internet Explorer 3.0 also includes security features, which may prevent some ActiveX controls from working with all Internet Explorer 3.0 configurations. This is most likely for older controls. In order for controls to work smoothly with Internet Explorer when it's active- content security is configured for the high safety level (which is the default), the controls must be marked as "safe for initialization" or "safe for scripting." If a control is used on an HTML page in a way that conflicts with its safety identification and the user's safety level, Internet Explorer does not create the control. See the "Safety API Reference" in the ActiveX SDK documentation for more information. Q. How do "lightweight OLE Controls" come into play? A. Typically, when someone uses this term, they are referring to controls that are written to be as small as possible, so they can be downloaded quickly. Lightweight controls are ActiveX controls, but may not implement all the required features of the older OLE Control specification. The ActiveX controls BaseCtl Framework (mentioned above) that ships with the ActiveX SDK samples provides small self-sufficient "lightweight" controls that are not dependent on associated DLLs (such as the MFC or Visual Basic runtimes). It should be noted that the BaseCtl Framework requires a solid understanding of OLE and COM technologies. The Active Template Library (ATL) was created to provide developers with a convenient mechanism for building lightweight and fast controls. If you want to know more about ActiveX controls, particularly on developing Web pages, check out another FAQ available on the "ActiveX controls" section of the ActiveX SDK page on http://www.microsoft.com/intdev/sdk/. Q. Why does Internet Explorer bring up a "Potential Safety Violation" warning when I try to display a page that contains a control I've written? A. Depending on how Internet Explorer's Safety Level is set, Internet Explorer brings up a "Potential Safety Violation" message box indicating that "the page contains active content that is not verifiably safe to display." Then, it either refuses to display the control, or it gives the user an option to allow it to be used. Internet Explorer is trying to protect the client workstation by refusing to execute content that may be unsafe. There are three ways to resolve this issue: - The first option: The end-user reduces the security settings of their browser via Internet Explorer's View\Options\Security\Safety Level option. This is the least appealing option because it reduces or disables security on all content displayed in the browser. - The second option: Control developers register their controls as implementing the "safe for scripting" component category. When Internet Explorer encounters an <OBJECT> tag, it uses the Component Categories Manager to determine whether or not the specified CLASSID is safe for scripting. - The third option: Control developers implement the IObjectSafety interface. More information about the second and third options can be found under the "Safety API Reference" in the ActiveX SDK documentation. Q. How do you register a control as a player for a particular file/MIME type? A. This information is available in the SDK documentation under \inetsdk\specs\register.htm. It is essential that you register an ActiveX object. Internet Explorer needs the registration to launch the correct player when it interprets the standard HTML <A HREF> tag, or Netscape's <EMBED> tag. Without the registration described in this document, it is impossible for ActiveX containers to guess what application to use to display or play an unknown media file. The document outlines the four steps necessary for registering your ActiveX control, including the special registry settings that allow ActiveX controls to do the following: - Launch with the <EMBED> tag (that is, without <OBJECT> and without CLSID specified) - Work full-frame (that is, for <A HREF> tags). Even ActiveX controls work full-frame, so you no longer need to have a DocObject to work full-frame (although controls won't get the full menu-negotiation, and so forth.) 1. Register the CLSID for the ActiveX object. 2. Associate the object's CLSID with a ProgId. 3. Associate the object with a MIME type. 4. Associate the file extension with a ProgId and optionally with a MIME type. However, information on how to get the file name from within your control is missing from the document. This is passed to IPersistPropertyBag as a parameter called SRC. Q. I'm trying to license my control. Is there a tool available for generating .lpk (license package) files? A. Use the LPK_TOOL that is part of the ActiveX SDK on inetsdk\bin folder. In the HTML page, be sure to insert an <OBJECT> tag, specifying the ClassID of the Internet Explorer license manager object, in addition to the <OBJECT> tag for the control you're licensing. For example, if you run the LPK_TOOL, add the Masked Edit Control, and save it out to Maskedit.lpk, your HTML code should look like the following: <OBJECT CLASSID="clsid:5220cb21-c88d-11cf-b347-00aa00a28331"> <PARAM NAME="LPKPath" VALUE="maskedit.lpk"> </OBJECT> <OBJECT CLASSID="clsid:C932BA85-4374-101B-A56C-00AA003668DC" WIDTH=200 HEIGHT=200></OBJECT> </OBJECT> More information on this can be found on the "Licensing ActiveX controls" section of the ActiveX SDK documentation and from article Q159923 in the Microsoft Knowledge Base. Q. Does Internet Explorer 3.0 support windowless controls? If not, when will support for this be available? A. No. Internet Explorer 3.0 does not currently support windowless controls, as it does not implement the IOleInPlaceSiteWindowless interface. Watch for this feature in future versions of Internet Explorer. Currently, you can work around this by embedding the HTML Layout Control in an HTML page. The HTML Layout Control is a container that supports windowless controls. It allows contained windowless controls to be transparent relative its background. Q. Is there an API to render JPEG/GIFs from an ActiveX control? A. Not currently, but as a workaround you could host the WebBrowser control and point it to the file in question. Q. I'm trying to build the WebImage sample, and I keep getting the error: "Cannot open include file: WImgInterfaces.H: No such file or directory". I searched my hard disk everywhere and this file is nowhere to be found. What did I do wrong? A. You'll run into this problem if you try to build the WebImage control sample within the Developer Studio environment (as opposed to running NMAKE /A from the command line, where it builds fine). The file WImgInterfaces.h is generated by the mktyplib call in the makefile. Make sure your Build.Settings are correctly set: - Go into Build.Settings, pick the ODL file and set the output header file to WImgInterfaces.h. - Make sure the Build.Settings match the MAKEFILE. More information on this can be found in article Q159967 in the Microsoft Knowledge Base. Q. Where do I get support for the controls in the Internet Control Pack? A. Other than the information provided in the Internet Control Pack Web site on http://www.microsoft.com/icp, Microsoft does not support any of the controls that are part of the Internet Control Pack (ICP). The controls included in the ICP are the FTP, HTML, HTTP, NNTP, POP, SMTP, WinSock TCP, and WinSock UDP controls. Questions on these controls, including information on subsequent releases, as well as customized versions should be directed to the following: NetManage http://www.netmanage.com 10725 North De Anza Blvd. Cupertino, CA 95014 (408) 973-7171 sales phone (408) 257-6405 fax (408) 973-8181 support phone More information on this can be found in article Q156692 in the Microsoft Knowledge Base. Frequently Asked Questions on ActiveX Documents Q. I'm trying to access a .vbd file from Internet Explorer and I keep getting the error: "Internet Explorer is opening file of unknown type: xxx.vbd." What is wrong? A. A number of things can cause this error to occur: - You are using the wrong .vbd file - You are using an outdated .vbd file - The Actxprxy.dll is missing or is not registered properly. - The ActiveX EXE/DLL is not registered properly. - VB Runtime is not installed or on the path. - The ActiveX Document may not be signed or safe for scripting. More information on this can be found from article Q167380 in the Microsoft Knowledge Base. Frequently Asked Questions on the WebBrowser Control Q. I'm using the WebBrowser control in my application. How do I redistribute it? A. You must obtain a redistribution license for Internet Explorer 3.0 and use the Internet Explorer 3.0 self-extracting executable (Msie30.exe) to install the necessary files and registry entries. You can license Microsoft Internet Explorer for Windows 95, Windows 3.1, Windows NT Workstation, and Macintosh royalty-free to redistribute within your organization or to your customers. Refer to article Q155969 in the Microsoft Knowledge Base for more information. Microsoft provides an online form to register your organization to redistribute Internet Explorer. This sign-up form is available on the IEAK page. Q. How do I print from the WebBrowser control? Although the WebBrowser control does not support a print method, you can print its contents using one of two ways: - Set focus to the Web Browser Control and send a key combination of Ctrl-P. -or- - Call the GetDocument() method, which returns an *IDispatch. Using this IDispatch pointer, call QueryInterface() on IID_IOleCommandTarget. With the object pointer returned, call Exec (NULL, OLECMDID_PRINT, 0, NULL, NULL): LPDISPATCH lpDispatch = NULL; LPOLECOMMANDTARGET lpOleCommandTarget = NULL; lpDispatch = m_ctlWebBrowser.GetDocument(); ASSERT(lpDispatch); lpDispatch->QueryInterface(IID_IOleCommandTarget, (void**)&lpOleCommandTarget); ASSERT(lpOleCommandTarget); lpDispatch->Release(); // Print contents of web browser control. lpOleCommandTarget->Exec(NULL, OLECMDID_PRINT, 0, NULL,NULL); lpOleCommandTarget->Release(); More information on this can be found in article Q156732 in the Microsoft Knowledge Base. Q. How do I change the font from a WebBrowser control? A. The WebBrowser automation model does not support a method that allows you to change the font of the text of the currently displayed page. The WebBrowser control, however, exposes this functionality through the IOleCommandTarget interface. Call the GetDocument() method, which returns an *IDispatch. Using this IDispatch pointer, call QueryInterface() on IID_IOleCommandTarget. With this IOleCommandTarget pointer, call Exec() with OLECMDID_ZOOM and use the pvaIn input argument to pass a value in the range of 0 to 5 (where 0 is smallest) indicating the desired scale of the font. In effect, this mimics the functionality available through Internet Explorer's View\Fonts menu: LPDISPATCH pDisp = NULL; LPOLECOMMANDTARGET pCmdTarg = NULL; pDisp = m_ctlWebBrowser.GetDocument(); ASSERT(pDisp); pDisp->QueryInterface(IID_IOleCommandTarget, (LPVOID*)&pCmdTarg); ASSERT(pCmdTarg); VARIANT vaZoomFactor; // Input arguments VariantInit(&vaZoomFactor); V_VT(&vaZoomFactor) = VT_I4; V_I4(&vaZoomFactor) = fontSize; pCmdTarg->Exec(NULL, OLECMDID_ZOOM, OLECMDEXECOPT_DONTPROMPTUSER, &vaZoomFactor, NULL); VariantClear(&vaZoomFactor); if (pCmdTarg) pCmdTarg->Release(); // Release document's command // target. if (pDisp) pDisp->Release(); // Release document's dispatch // interface. More information on this can be found in the IEZOOM sample described in article Q156693 in the Microsoft Knowledge Base. Q. I'm trying to host the WebBrowser control from a non-MFC application using CoCreateInstance(). How do I do this correctly? A. Many controls, including the WebBrowser control, require that the container support certain OLE document/Control Site interfaces in order for the OLE Automation calls to work. These interfaces provide the visual containment for the control. An application that does not care about the visual containment of the control can create an instance of Internet Explorer, instead of the control, with code similar to the following: hr = CoCreateInstance(CLSID_InternetExplorer, NULL, CLSCTX_SERVER, IID_IUnknown, (void **)&g_pUnk); hr = g_pUnk->QueryInterface(IID_IWebBrowserApp, (void **)&g_pIWebBrowserApp); g_pUnk->Release(); g_pIWebBrowserApp->GoHome(); An application that needs visual containment of the control has to support the OLE Documents/Control Site interfaces described in \InetSdk\Specs\OCGUIDE.DOC. The WebBrowser control is a control written according to the OLE Control 94 specification, and therefore the containing application should implement the corresponding interfaces described in the document. Frequently Asked Questions on Code Download Q. I need to package the MFC 4.2b dependent DLLs with my ActiveX control. What's the best way to do this? A. The MFC 4.2b dependent DLLs are available as a signed .cab file at the MFC 4.2b CAB Download page. The URL for this CAB file is http://activex.microsoft.com/controls/vc/mfc42.cab. By clicking on this link, you'll install the files on your machine. You can include this link on your Web sites that require MFC 4.2b so your users can install the DLLs at their convenience. This .cab file installs the following files: Name Version ---------------------- Mfc42.dll 4.2.6256 Olepro32.dll 4.2.6068 Msvcrt.dll 4.20.6164 Q. What version do I specify in the CODEBASE attribute of my <OBJECT> tag, especially when pointing to a .cab file? A. The #Version information applies to the control specified by the CLASSID parameter of the <OBJECT> tag. Q. How do I version stamp a CAB? A. Instead of putting a version on the .cab file, the .inf file inside the .cab should specify the version. The .inf file should have a file section that specifies a version and the same classid specified in the <OBJECT> tag. As illustrated in the example below, this file version specifies the version of the ActiveX control to be downloaded. Example .inf file section: [circ3.ocx]  ; The lines below specify that the specified Circ3.ocx (clsid,  ; version) needs to be installed on the system. If it doesn't exist  ; already, can be downloaded from the given location (a .cab). NOTE:  ; if "thiscab" is specified instead of the file location, it is  ; assumed that the desired file is present in the same .cab cabinet  ; that the .inf originated fromotherwise, if the location pointed to  ; is a different .cab, the new cabinet is also downloaded and  ; unpacked in order to extract the desired file. file=http://www.code.com/circ3/circ3.cab clsid={9DBAFCCF-592F-101B-85CE-00608CEC297B}  ; Note that the {}s are required when entering the CLSID in the .inf  ; file. This is slightly different from the HTML syntax for inserting  ; CLSIDs in an <OBJECT> tag. FileVersion=1,0,0,143 Q. Is there a way to see a debug trace of code download activity? This will really help me with debugging. A. Yes, there is a way to do this with the help of the DEBUG versions of Urlmon.dll and Wininet.dll: 1. Make sure you have the DEBUG version of these DLLs installed in your system. They should be located in the \INetSDK\DEBUG folder. Although these DLLs are part of the core SDK available for download on the Web, they are not installed as part of the regular SDK setup. If you do not have the \INetSDK\DEBUG folder in your ActiveX SDK installation, use the following steps: - Go to the ActiveX SDK download page. - Select the "ActiveX SDK Core Components" from the drop-down list. - Follow the instructions to download and extract the SDK files. - Verify that the \Inetsdk\Debug subdirectory contains the debug versions of Urlmon.dll and Wininet.dll. - Back up your system Urlmon.dll before replacing it with the debug version; otherwise you may render Internet Explorer unusable or your system unbootable. - When you no longer need the DEBUG version of Urlmon.dll, restore the non-debug version of Urlmon.dll back to your system. 2. Add the following entry to your Win.ini file: [urlmon] urlmk=0xFF200000 3. Replace the retail version of Wininet.dll and Urlmon.dll with the debug version. Be sure to back up these system DLLs before replacing them with the debug version. Otherwise you may render Internet Explorer unusable or your system unbootable. 4. Open an MS-DOS prompt. 5. At the prompt SET WININETLOG=1. 6. At the prompt start Iexplore.exe. 7. Navigate to your desired URL, such as http://www.microsoft.com/. 8. Shutdown Internet Explorer. 9. Examine the file Wininet.log, which should have been created on your desktop. Q. I notice that some controls and dependent files are not updated even when a newer version is specified in the CODEBASE. The first download seems to succeed fine, but subsequent downloads with newer versions fail to update the affected files. What is wrong? A. Among the files we've seen that have this problem are: Vbajet32.dll and the HTML Layout Control files P2d.dll, Fm20.dll, and Isctrls.ocx. These files fail to indicate their target operating system in the dwFileOS field of the VS_FIXEDFILEINFO structure defined in the version stamp resource. Since this field is set to VOS_UNKNOWN, the download fails. Frequently Asked Questions on Internet Explorer's Object Model Q. How do I access Internet Explorer's object model from a contained control? A. Internet Explorer supports an Automation interface called IWebBrowserApp. It also supports an object model for scripting through a hierarchy of interfaces. The root dispinterface of this model has one property, Script, which returns the dispinterface for the window scripting object described in the ActiveX documentation. From a contained control or doc object, you can get the dispinterface for IWebBrowserApp with the following code: IOleClientSite* pClientSite; // Already points to the control's // client site. IServiceProvider* pISP; IDispatch* pIEIDisp; pClientSite->QueryInterface(IID_IServiceProvider, (void **)&pISP); pISP->QueryService(IID_IWebBrowserApp, IID_IDispatch, (void **)&pIEIDisp); To get the root scripting model dispinterface, given that you already have the ISP pointer as above, you can use this code: IDispatch* pScriptIEDisp; pISP->QueryService(SID_SContainerDispatch, IID_IDispatch, (void**)&pScriptIEDisp); Please note that the actual interface names of the scripting interfaces, such as the interface for the window object, are subject to change and should be used only via late binding. Q. Is there a way to launch Internet Explorer and have it open a URL? A. Yes, this is done through the magic of OLE Automation and the InternetExplorer object. The InternetExplorer object allows an application to create and manipulate an instance of Internet Explorer through OLE Automation. Here's how you can launch Internet Explorer 3.0 in Visual Basic, for instance, and have it open the Microsoft Web page at http://www.microsoft.com/. Note, however, that this method launches a new instance of Internet Explorer every time. Dim Explorer As Object Explorer = CreateObject ("InternetExplorer.Application") Explorer.Navigate "http://www.microsoft.com/" Explorer.Visible = True More information on the InternetExplorer object can be found on the ActiveX SDK page under the "IE Object Model" section. Another way an application can launch Internet Explorer, and have it navigate to a specified URL, is through Dynamic Data Exchange (DDE). Internet Explorer provides support for DDE so that applications can talk to a currently running instance of Internet Explorer, or even open a new Internet Explorer window. Applications can communicate to Internet Explorer in this manner by establishing a DDE connection with Internet Explorer, specifying iexplore as the appName, the verb WWW_OpenURL as the topicName, and the desired URL, say http://www.microsoft.com/, for its XTYP_EXECUTE string. More information on the extent of DDE support Internet Explorer provides can be found on articles Q160976 and Q160957 in the Microsoft Knowledge Base. Q. When I build the ObjVw sample for the Alpha platform, I get an error M0003 from MKTYPLIB. What's wrong? In Objvw.odl, the line that reads the following: importlib("stdole32.tlb"); should be changed to the following: importlib("stdole2.tlb"); Frequently Asked Questions on WinInet Q. How do I get WinInet to work correctly in Windows NT 3.51? A. WinInet requires enhancements for asynchronous operations, which are only available with Windows NT 3.51 Service Pack 4 (SP4). Be sure to install SP4 when you are running WinNT 3.51. Also, verify that you're using Wint351.exe, which installs Wininet.dll and dependencies on WinNT 3.51. Refer to the ActiveX SDK's Readme.txt file for more information. Q. Why do I get such strange behavior when calling my WinInet functions? A. When you are writing your application using the ActiveX SDK, verify that you are using the Wininet.dll that matches the version of your Wininet.lib and Wininet.h. You will need to install Wininet.dll using Wintdist.exe or Wint351.exe, the self-extracting utilities provided for redistributing Wininet.dll with your application. Note that these self-extracting redistributables are available as a separate download from the ActiveX SDK Download page. To install the redistributables, select the "ActiveX SDK Redistributables for Windows 95/NT 4.0" from the drop-down combo box. A version mismatch between the Wininet.dll and the .lib/.h can obviously produce some very strange results. Q. Why do I keep getting the message: "Error initializing the cache ..." when I try to use the WinInet APIs from my service? A. The complete error message comes up as follows: Error initializing the cache. Shut down all programs and run ScanDisk or ChkDsk. Delete the cache, cookies, and history directories in your WINDOWS directory and then restart IE. If the problem persists, reinstall IE. Microsoft has confirmed this to be a problem with the WinInet cache that occurs whenever WinInet is first loaded in the context of a service, such as an ISAPI filter, and then by a user process, such as a browser like Internet Explorer 3.0. As a workaround, either try not to use any IIS filter DLLs that use WinInet, or make sure a user-mode WinInet application is running before you start the IIS service--that is, you can manually start the IIS service after running Internet Explorer 3.0. This causes the WinInet cache to initialize in the user-mode context of Internet Explorer 3.0, thus preventing any filter DLL using WinInet from locking out other user-mode programs from the cache. Refer to article Q160060 in the Microsoft Knowledge Base for more details. Q. I notice that Wintdist.exe does not run unless I'm logged on as an ADMINISTRATOR in Windows NT 4.0. Is this expected behavior? A. This is a limitation imposed by Windows NT security, particularly as a result of the registry being secure under Windows NT. Wintdist.exe is a self-extracting executable that not only installs the Wininet.dll into the system, but also writes information into the registry. Because not all users have access to all keys in the registry, the executable fails unless it is run with ADMINISTRATOR privileges. Q. What's the difference between PragmA.No-Cache and the Expires:0 header? A. Although an HTTP 1.0 client, such as Internet Explorer 3.0, is not required to do anything with "PragmA. no-cache", Internet Explorer 3.0 honors this header for SSL by not creating a download file. "Expires: 0" is set if you want the browser to verify with the server and if the URL needs to be refreshed. Q. Why don't WinInet FTP APIs work over my proxy? A. WinInet understands two proxy types: the TIS (Trusted Information Systems) FTP gateway (FTP) and the CERN (HTTP). WinInet FTP APIs (such as FtpPutFile, FtpGetFile, and so forth) cannot be used with CERN-type proxy. CERN proxy presents data as HTML, which does not work with the FTP APIs. It is still possible to get a file from the FTP or GOPHER server through a CERN proxy either by making HTTP requests, or by using InternetOpenUrl() as follows: InternetOpenUrl (hInternet, "ftp://MyFtpServer/MyFtpFile.txt", ...) InternetReadFile (); Frequently Asked Questions on Other Related FAQ's Q. Where can I find JScript documentation? I can't seem to find it in the SDK. A. There is no JScript specific document. JScript is exactly like JavaScript syntactically. The Scripting Object Model document applies to both VBScript and JScript because both are language engines calling a common model. Almost all questions are answered in this document. Refer to JScript Web Page (http://www.microsoft.com/scripting/jscript/) for more information, as well as to the FAQ (http://www.microsoft.com/scripting/JScript/us/techinfo/jsfaq.htm) available off that page. Q. Where can I find VBScript documentation? A. Documentation for VBScript is available on the VBScript Web Page (http://www.microsoft.com/scripting/vbscript/), which is updated frequently. There is also an FAQ (http://www.microsoft.com/scripting/vbscript/us/techinfo/vbsfaq.htm) available on that page. Q. Where can I learn more about the Scripting Debugger? A. You can learn more about it from the Windows Script Technologies page at (http://msdn.microsoft.com/scripting/debugger/default.htm). Q. Are there any other FAQs on related topics that I should know about? A. Yes. Check out the ActiveX SDK Page (http://www.microsoft.com/intdev/sdk/). Scroll through the various topics on the left frame and you'll find FAQs on the following: ActiveX Controls: http://www.microsoft.com/intdev/controls/ctrlfaq.htm Java: http://www.microsoft.com/java/sdk/getstart/faq001.htm Internet Security Framework: http://www.microsoft.com/intdev/security/faq4.htm Authenticode/Code Signing: http://www.microsoft.com/intdev/security/authcode/signfaq.htm dbWeb: http://www.microsoft.com/intdev/dbweb/dbwfaq.htm Additional query words: Keywords : AXSDKWinInet AXSDKIEScripting AXSDKWebBrowser AXSDKWebPost Version : WINDOWS:1.0 Platform : WINDOWS Issue type : kbinfo

Last Reviewed: November 25, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use.