× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Antonio

Coming from someone (myself) who loves to make things too complicated, let me say that I think the DLL is definitely a little bit much. An ActiveX control can be considered to be a DLL with some nice bits added to make it easier to use in various development environments.

My feeling on whether to stay in Access is, it depends. You can write full-blown applications with Access that have all the "functions" you want - again, take a look at the samples you get with it, esp. the Northwind one. You can also call functions in a DLL or OCX (ActiveX control) from Access. You just need to add the ActiveX to your project, I think. I see that ActiveX's can be managed from the Tools menu, and what are called references can be added in the VBA editor that is used for modules.

DLLs can be used but are generally more difficult to work with - you have to get all the data types right when you declare them, I don't see a way to do it outside the module VBA editor (haven't tried either). And an OCX takes care of a lot of this kind of thing. Still, it is an extra layer you might not need in either case.

The main reason to do an OCX or DLL would be, in my opinion, to have something to use other than in Access - everything you want to do is available already in Access.

Again, are you in control of what the database is? Do you create the MDB? Are your users adding their own forms, or are you or a developer providing them? You could provide these lookup forms with the database and the users could just call them - make sure to tell them how. Then you have only the one object to distribute (essentially) - the MDB.

What do you think?

Vern

At 07:17 AM 6/10/2006, you wrote:

Thanks Vern for your comments.
The reason I'm not willing to do it in Access 2003 itself is : I'd like
to provide customer with a "Function" to provide the interface for
asking the Customer_ID. Another Function to find out Item_ID, etc
Since they are developing quite a number of Application Forms dealing
with Customers, Items, etc, then , if done directly in Access, I think
they would have to implement the link to search for Customer or Item,
etc in many other different places/times... If I provide them with a DLL
that includes/embebs those Functions, I think they'd find it more
"transparent", ... and standardized (always the same). Or, am I
complicating things up?
ActiveX I've never dealt with, but maybe is the way to go?
Personally, I think Functions "Ask_Customer", "Ask-Item", etc, if
available directly from within a DLL , are more clear for the Customer...
Am I wrong?

Vernon Hamberg escribió:

>Short answer - certainly, this is possible. But
>an even shorter answer - why not do it in Access
>- you already have VBA in Access that can do all
>the prompting you need. What you are asking for
>is just another form, as I understand it. I
>suggest opening up the Northwind example and take
>a look at the various forms in there.
>
>But if you need something that will be used in
>more than Access, get your copy of VB and get
>started. When you open a new project you are
>asked what kind of thing you want to create,
>whether an executable or a DLL or an ActiveX
>control or some other option. You might want to
>consider an ActiveX control, instead of a DLL -
>easier to use in Access. All the information you
>need to get going is in the various help
>resources of VB, especially the Microsoft
>Developer's Network (MSDN) CD that usually comes
>with VB or you can go to
>http://msdn.microsoft.com and rummage around.
>Lots of tutorials, sample code, etc. I have found
>Delphi to be not as easy to get into as VB, but
>if you know Delphi, then there are similar
>resources for getting going. As for VB, I don't
>really know whether to recommend .Net or VB6 -
>they are similar but different enough that it can
>be messy going to .Net from 6, I understand.
>Others will have opinions here, and, of course,
>M$ wants you to go to the latest and greatest. Of
>course, .Net is current, so might be the way to
>go if you have done no VB work before.
>
>BTW, MSDN also has the documentation and examples, etc., for Access.
>
>HTH
>Vern
>
>At 03:55 AM 6/10/2006, you wrote:
>
>
>
>>Well, maybe I did not make myself clear...
>>Let me try to explain it better this time:
>>As I see it, any "Function" , in any language, is "a program (or
>>whatever)" that can be invoked from another program (Application) to do
>>some work and return a result value.
>>What I'd like to write is a "Function", could be called
>>"Ask_Customer_ID", that would present some displays (windows) with
>>search criteria, show a list (ListBox) of those that qualify for the
>>entered search criteria, allow for selection, and return the selected
>>Customer_ID.
>>Any Access Form that needs the customer_ID (Order Entry, or Invoicing,
>>etc) asking the user for Customer_ID could then have a "Command Button"
>>that, when pressed, would call Function Ask_Customer_ID" to get it
>>returned and go on with other processing...
>>
>>That function (and, possibly, others...) could be "encapsulated" (???)
>>in a .DLL to be used "where needed".
>>Can this be done? Any example of how to do it?
>>But from Access2000 Help (and I guess Access2003 would be the same...)
>>searching for "Call" (Action Execute Code):
>>    "Microsoft Access ignores the value returned by the Function" (??? !!!)
>>Then, maybe, passing the Customer_ID as a ByRef parameter?
>>
>>Hope I made myself more clear this time.
>>TIA
>>
>>Shannon ODonnell escribió:
>>
>>
>>
>>>So...I'm not following this completely here... are you wanting to have a
>>>customer number (and all key fields) prompt that then writes the values to a
>>>file which could be read by your Access and other apps?
>>>
>>>And you're wanting it such that from within Access or Excel or whatever, you >>>can execute this new app to display the prompt. And your goal is so that the >>>single prompt provides a uniform look and feel to all the apps, writing the
>>>data to a single file on the hard drive?
>>>
>>>Is that what you're after?
>>>
>>>-----Original Message-----
>>>From: pctech-bounces+sodonnell=irish-studios.com@xxxxxxxxxxxx
>>>[mailto:pctech-bounces+sodonnell=irish-studios.com@xxxxxxxxxxxx] On Behalf
>>>Of Antonio Fernandez-Vicenti
>>>Sent: Friday, June 09, 2006 8:58 AM
>>>To: PC Technical Discussion for iSeries Users
>>>Subject: [PCTECH] VB/Delphi "kind of" Service Program_DLL
>>>
>>> Customer is using Access/2003 for several apps. Several of them start
>>>asking for something like "Enter Customer Number", so we'd like to just
>>>implement such a Function just once and have all initial Forms for each
>>>app, when users is promted for "enter CustomerNo" either answer with a
>>>number (if he knows it) or , else, press F4 (or whatever, or a Button)
>>>to "call a Function" that will do the work: e.g. present a new Form
>>>asking for key values (LastName starting chars, FirstName starting
>>>chars, CityAreaCode, etc. Then show customers that fulfill those
>>>requirements, allow for selection of one of them , ... just to return
>>>the selected code or a "not found" value... to the original App.
>>>
>>>Such a Function would be used throughout in several different Apps. I
>>>think one (best one???) of the alternatives would be to develop a
>>>"CustomerSelect Function, receiving no-parms, returning one integer(or
>>>zero, maybe) value of selected CustomerCode.
>>>This Function could/should be writen either in VB or Delphi, then create
>>>a  .DLL with that Function, to register under Windows, to be used for
>>>any VB projects that need it.
>>>I think of it as a "ServiceProgram" in RPG... but as a DLL.
>>>
>>>Anyone out there willing to share an example (either VB and/or Delphi)
>>>of such a Function?
>>>TIA
>>>
>>>Antonio Fernandez-Vicenti
>>>afvaiv@xxxxxxxxxxxxxx
>>>
>>>
>>>
>>>
>>>
>>--
>>Antonio Fernandez-Vicenti
>>afvaiv@xxxxxxxxxxxxxx
>>
>>
>>--
>>This is the PC Technical Discussion for iSeries Users (PcTech) mailing list
>>To post a message email: PcTech@xxxxxxxxxxxx
>>To subscribe, unsubscribe, or change list options,
>>visit: http://lists.midrange.com/mailman/listinfo/pctech
>>or email: PcTech-request@xxxxxxxxxxxx
>>Before posting, please take a moment to review the archives
>>at http://archive.midrange.com/pctech.
>>
>>
>
>
>
>

--
Antonio Fernandez-Vicenti
afvaiv@xxxxxxxxxxxxxx


--
This is the PC Technical Discussion for iSeries Users (PcTech) mailing list
To post a message email: PcTech@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/pctech
or email: PcTech-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/pctech.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.