Wrox Programmer Forums
Go Back   Wrox Programmer Forums > Microsoft Office > Access and Access VBA > Access
|
Access Discussion of Microsoft Access database design and programming. See also the forums for Access ASP and Access VBA.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Access section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old February 20th, 2006, 03:40 PM
Registered User
 
Join Date: Dec 2005
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default How to get rid of everything except startup form.

I would like to set my startup options so that only a form is loaded. I already figured out how to get rid of the database menu, but I can't figure out how to get rid of the actually Access menu that has the dark grey back ground and "File" "Edit" etc at the top. I did a search on the forum and most of the previous responces suggested that the designer maximize the form size (which wouldn't work for me) or add in a macro that minimizes the size of the access window.

Does anyone know how to actually set up this macro, or any other work arounds? I appreciate your help with this. My ultimate goal is to make the form that is loaded to look like an actual program as opposed to a form run from within Access.

Thanks
Mike

 
Old February 21st, 2006, 11:14 AM
Friend of Wrox
 
Join Date: Mar 2004
Posts: 3,069
Thanks: 0
Thanked 10 Times in 10 Posts
Default

Your best bet is to compile the application to an mde file or build the application in VB.Net

Alternatively, when your main form loads, add code like this (On Load event):

CommandBars("Form View").Enabled = False

This will get rid of the button menu. You will have to look up the syntax for the other view you want to get rid of.

This will not suppress right click menus, so mde or VB.Net is still your best bet. Wrox has some great books on moving in that direction with your development.

HTH



mmcdonal
 
Old February 21st, 2006, 11:26 AM
Friend of Wrox
 
Join Date: Jan 2005
Posts: 471
Thanks: 0
Thanked 1 Time in 1 Post
Default

Big Lazy,

There are ways to eliminate everything so your Access application looks like a standalone app. The problem is positioning and sizing each and every form in your app. Also, when you close the app, you have to make sure you resize Access otherwise Access will be minimized each time you open it. I have a small app that shows pretty much how to do it, so if you want, send me an email address and I'll send it to you.

Kevin

dartcoach
 
Old February 22nd, 2006, 11:27 AM
Registered User
 
Join Date: Dec 2005
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Ok I figured out how to do this with a lot of help from a couple different message boards. I used the script on this page http://www.mvps.org/access/api/api0019.htm to create a new vba module. When access opens I set the startup options (tools - Startup) so that my main form opens automatically. Under the events properties for that main form I made code that on open:
Me.Visible = True
fSetAccessWindow (SW_HIDE)
fSetAccessWindow is the name of the new module that was created using the code at the link above.

I also had to set the modal and popup to yes for all of the forms that I would want the user to use. I also had to add exit database buttons to all of the forms and turn off the close button on the forms. If a user accidently would have hit X instead of the exit database button I created, then access would freeze. Now my access dbs looks like a real program with the exception of the warning message the access gives when it first starts up. It says that code may be harmful to the computer.

Does anyone know how to get rid of that message? Also how tough is it to learn VB.net and what software do you need for it? Oh and what does it look like when you convert to MDE file. Is there a visual difference or is it just that all of your code is protected?
 
Old February 22nd, 2006, 11:39 AM
Friend of Wrox
 
Join Date: Mar 2004
Posts: 3,069
Thanks: 0
Thanked 10 Times in 10 Posts
Default

For a BigLazy, you did a lot of good work here.

The warning you get is a function of the security settings in Access 2003. You can lower the settings or get a cert, which I think will stop this.

For VB.NET, you can use any supported IDE, like MS VB.NET (about $100) or Visual Studio, or PrimalScript, which supports tons more languages than just about any other.
VB.NET, VBA, and VBScript are all very similar. VBA is probably the least powerful, followed by VBSCript, then VB.NET. But if you know VBA, .Net is not difficult to learn. And Wrox has some great books to get you started.

HTH




mmcdonal
 
Old February 22nd, 2006, 02:35 PM
Registered User
 
Join Date: Dec 2005
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Ok now I got a new problem. one of the forms that displays correctly is used to create reports. Now when I try to open the reports using this form, the reports won't load. I changed the properties on the forms so that the modal and popup are "yes" but that didn't change anything. I also tried changing the actual script used to bring up the report, as well as changing it's visibility on load,but neither seems to work.

If anyone has any ideas or suggestions I would appreciate hearing them. I also might try just exporting the reports right to Word and bypassing looking at the form in Access all together. Any pointers on that would also be appreciated.

thanks
mike



 
Old February 22nd, 2006, 09:06 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Code:
 Also how tough is it to learn VB.net and what software do you need for it?
Had to chuckle a little, 'cause my original reply to your post was gonna be "don't use Access if you want a form that doesn't look like its running in Access!"

The first part of your question, "how tough is it to learn VB.net", really reduces to "How hard is it to learn true object-oriented programming", cause thats what the shift from Access/VBA (even VB to a lesser extent) to VB.NET, or any other .NET language, would really be all about. The language isn't harder to learn than any other, just study the on-line help. But learning to think differently as you make the leap from procedural to object-oriented programming is definitely challenging. For example, VBA supports some object-oriented features, like class modules. But you can work with Access/VBA your entire life, and never have to write one (the topic is practically never discussed, for example, on this forum). In .Net languages, all you write are classes, and your classes inherit from other classes, and override methods in base classes, and get cast as base classes to behave polymorphically, etc. Of course, you write other types as well, interfaces, structures, enums, delegates. But there is no such thing as VBA/VB standard modules or sub procedures/functions (though static methods in .NET classes sort of resemble VBA/VB sub procedures/functions in standard modules). In .NET, everything is an object, and objects have methods. Even the primitive data types, like Integer and String, are structures or objects with properties and methods of their own. In VBA you think in terms of procedures; in .NET, you think in terms of objects. There is nothing trivial about the switch from VBA/VB to .NET because there is nothing trivial about the switch from procedural to object-oriented programming, but its the best move you can make if you're serious about programming.

However, I'd strongly suggest learning C# instead of VB.NET. Again, the language is no harder to learn than VB.NET (once you get used to the curly braces). But there is a larger C# mindshare out there to tap into than you'll find for VB.NET (as evidenced by, for example, the number of C# vs. VB.NET applicants for MCAD/MCSD Certification exams, and the respective size and quality of the languages blogging communities). In short, more folks are doing more interesting things with C# than VB.NET.

Finally, the other steep learning curve aspect of moving to .NET, regardless of language preference, involves learning the architecture of the .NET framework development platform itself. You'll run into all kinds of totally brand new things like managed code, garbage collection, assemblies and how to disassemble them into intermediate language to view the code that really makes your apps run (regardless of source code language), the classes available in the .NET Framework Class Library (thousands of them), how the Common Language Runtime Works, and what the types in the Common Type System are. When I started writing C# apps about three years ago, I just skimmed this stuff, which made learning C# a lot more conceptually difficult than it needed to be. So here's my last piece of advice: Read Jeffrey Richter's "Applied Microsoft .NET Framework Programming"!!!!! Then read it again!! (It's written in C# by the way).

What do you need to run it? Get VS.NET 2005 Pro. Or you could just download the Framework which includes the language compilers and write your programs in note pad (just kidding, though you could). Or download SharpDevelop, an open source version of the VS.NET IDE from http://www.icsharpcode.net/. Wrox even published a book on it, "Dissecting a C# Application: Inside SharpDevelop".

The move from VBA/VB to .NET ain't easy. There are enormous differences between languages and platforms. But do it, and you'll be thanking me a year from now.

Bob



 
Old February 22nd, 2006, 09:39 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

I mentioned Richter's must have book, but the truth of the matter is that the vast majority of the must have .NET books are written in C# (the whole Wintellect crowd and a plethora of others).

Bob

 
Old February 22nd, 2006, 11:22 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

 
Quote:
quote:...there is a larger C# mindshare out there to tap into than you'll find for VB.NET (as evidenced by, for example,...


The P2P forums: (not including the ASP.NET folks)

C#
1055 Topics, 3021 Posts

VB.NET
234 Topics, 629 Posts

which translates into more (about 5 times more) quality resources for you. C# is, or so some say, slowly becoming the VB of the future, now tha MS has discontinued development and support for "classic" VB (though about 100 MS MVP's are pretty irked about that and are currently petitioning Redmond to reconsider its position).

Bob


 
Old March 23rd, 2006, 07:33 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Quote:
quote:
In .Net languages, all you write are classes...there is no such thing as VBA/VB standard modules or sub procedures/functions (though static methods in .NET classes sort of resemble VBA/VB sub procedures/functions in standard modules). In .NET, everything is an object, and objects have methods.
Just can't let that one slide!! Been about a year since I worked with VB.NET (been going after C# primarily) but revisted it recently. VB.NET DOES still have a Module object in which you can run Subs and Functions without having to instantiate an object. In C# "all you write are classes" (no Module object), though C# static methods emulate VB.NET module-like behavior: you don't need to instantiate an object to call them. I feel much better now...

Bob






Similar Threads
Thread Thread Starter Forum Replies Last Post
how to set a form as startup form in vb.net 2.0 mallikalapati .NET Framework 2.0 1 February 21st, 2008 09:19 AM
User Form: How to get rid of icon "X" Axxess Excel VBA 2 September 26th, 2005 05:34 AM
Get rid of the close button on a form Piblon Excel VBA 6 June 30th, 2004 02:15 AM
Form Startup Order NeilS21 Beginning VB 6 2 February 26th, 2004 05:44 AM
Global instantiation of startup form hilda007 VB.NET 2002/2003 Basics 5 February 21st, 2004 01:56 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.