1

In a MS-Access application with more tha 50 different forms(windows) we require that users must exit in a specific order in order to save certain system specific data. However some of our users do not follow this procedure and instead they click on the X in the upper right corner which terminates the Access session and leaves critical information in limbo. What i would like is to either disable that pesky X button or at least intercept it in code so that we can take the proper action to save critical data and then terminate the session.

2

Check on Elance. all of the low-cost (overseas) labor is there …Now that 35k would have cost 1k (that’s 10’s of hundreds instead of thousands…). Now we can always find highly talented low cost labor if we really want to… Heck, the overseas developer would be happy to do the 35k project for 1k, that’s a fortune to him…a couple of years wages to him. Of course that would put you and I out of work so don’t spread that around… :slight_smile: I would love to be on the receiving end of your budget ! :slight_smile: … What all was there entailed with this 250k project ? I would say someone got the shaft… even at the lower 35k…With IT, we all know how dependable IT can be in keeping things in budget when it involves other’s funding. If it could have stayed on Access… it possibly should have…You did the right thing in not letting IT getting their grubby hands on it. IT has a way of making things look as if they would need to cost a lot… I’ve been in IT for some 30 years ( when IT was known as MIS) and seen it happen… They will often say Oh you need this… but they often have stretched the truth… Not so much in the past, but now there are so many low-cost solutions out there…open source to be included… Plenty of places to get programming help… (ITToolbox is only one of many such places for GREAT advice and expert help…!). Yep, when it can stay in Access then keep it there, but when it outgrows the bucket, get a bathtub…

3

Bruce, I don’t doubt the need to upgrade, but I do wonder about your cost estimates. I was part of a team building an Access tax engine. When IT saw what it could do, they said it would have cost them 250k to build and we did it for about 30k in labor. Then down the outsourced road we contracted to build a supply chain mgmt SQL app. The cost was 35k and it was no more complicated than this db

4

Absolutely on the Expense ? Hmmmmm. Depending on the situation (as describe by “a multitude of other considerations” above), it may be proper to stay with Access for the time being for smaller projects, but when they grow as they almost always do… up-scaling is a necessity… but the statement of it costing 10’s of thousands of dollars? Hmmmm NOT !
.
Also depending on the complexity of the app itself will obviously have varying costs… but as I mentioned in my reply above… most costs are minimal NOT 10’s of thousands…
.
The ease of migration and expense is not as bad as people think it is… since you would be going from a MS product to another MS product (a FREE one with SQL Server Express)… .Net developers are a dime (not 10’s of Thousands) a dozen… Just outsource it to some far eastern or European developer and and will cost you next to nothing when compared with in-US costs… even large complex projects… check on Elance.com or Freelancer.com.
.
Of course one variable is how well the app is kept, maintained, AND documented… :slight_smile: I admit myself that I can do a better job of app documentation…

Cheers !

5

Nick

Thanks for your suggestion and input. We have found the resolution to our issue.

6

Thanks to ALL for your input!
But I did NOT intend to have this question turn into a prolonged discussion on the pros and cons of what method to use to implement an APP. Although, I must confess, it is truly interesting to read the varying ideas put forth.

Thanks again to ALL

7

LukeChung

Thank you for your support. We have implemented the procedure as outlined in a Microsoft KB article and it seems to perform just fine and is exactly what we were looking for. You are absolutely correct with your statement of expense to convert to .NET, besides that, there are a multitude of other considerations that would make it unreasonable to convert the App to .NET at this time.
Thanks again.

8

Thank you for your reply?. I have found the resolution to my issue.
BTW: Your recommendation of issuing Warning Messages and then ‘disciplining’ the user is much too user-unfriendly in our environment.

9

Thank you for the reply. I have found the solution to my issue.

10

We had a similar problem on key input forms and have cured all problems by controlling what the user can do by replacing any ability to close the form or Access with specific close procedures.

At the form level set Close Button property to No and Model to Yes (prevents users switching to other forms whist current form is open. Add a specific close button to the form and you can control how the form is closed and the next form to be displayed.

To prevent users circumnavigated the restriction by closing Access, hide the main Access close button by introducing the two modules listed below. Call the Hide function when you are in an area where you do not want the user to be able to leave Access and call the Unhide as part of a form close when it is safe for them to close Access.

Sub HideAccessCloseButton()
Dim lngStyle As Long
lngStyle = GetWindowLong(hWndAccessApp, GWL_STYLE)
lngStyle = lngStyle And Not WS_SYSMENU
Call SetWindowLong(hWndAccessApp, GWL_STYLE, lngStyle)
Call SetWindowPos(hWndAccessApp, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE Or SWP_DRAWFRAME)
End Sub

Sub UnHideAccessCloseButton()
Dim lngStyle As Long
lngStyle = GetWindowLong(hWndAccessApp, GWL_STYLE)
lngStyle = lngStyle Or WS_SYSMENU
Call SetWindowLong(hWndAccessApp, GWL_STYLE, lngStyle)
Call SetWindowPos(hWndAccessApp, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE Or SWP_DRAWFRAME)
End Sub

The Hide function could be included in your opening form if you introduce specific close buttons on all forms; otherwise include it in calls to critical forms where you have introduced your own close button / procedure.

Nick Peek
Friendly Data Solutions Ltd

11

Hmmmmmm… 10s of thousands of dollars to migrate some 50 forms and numerous reports to VB.Net ? I need that job…

You are right about the part of just preventing the close button is hardly a reason to migrate…and no you would not use the back-end to prevent the use of the Close button… There are other reasons as well as advantages for migrating as Michael mentioned… For one, the reports can stay in Access… just write the code in VB.Net or C# to run them… but pretty soon apps out grow Access… another reason to migrate…

Now Access is good in many ways,. I use it myself… It is quick and easy for the small stuff… Heck just pick up an Access For Dummies book and you can do a very useful app in no time… even become a company expert after you read the book… :slight_smile:

I am sure the technique you sell may be reliable… and it certainly is an option. That may not be the only issue. Just as the prevention of the Close button may not be the only benefit…but I would agree with Michael. Any app that is growing large should be migrated… Access is not meant to be a multi-user app… It was originally designed to be a single user PC db… to compete with dBase. Hence the power of VB.Net (or C#) and Access combo or the VB & SQL Server Express combo… It can be upscaled rather nicely… The cost ? VB developers are a dime a dozen… take your pick… I can here all the VB developers snickering… Is it not stretching it a little with that cost statement ? :slight_smile:

Converting to SQL Server… no brainer… you can migrate it to the FREE version of SQL server. This will give you the scalability (one of the other reasons besides preventing the use of the Close button.)

VB & C# with SQL Server combo is FAR more flexible than Access is… you can have more control, etc… ROI is far more evident in the long run than Access…

Over all it would be easy to do it… Cost? heh, post a project up on Elance.com or Freelancer.com… yuo can get all the developers you want from over-seas that bid at $5 an hour… or bid on a project that may be worth here for $1000 or $2000, and they bid $50… Many of those developers can run circle around the ones in the US… I am sorry to say…

Access is a great tool to start out with… I can do some real quick stuff that looks real good to my customers… I use it to model apps that I later write in something else… I love using Access… for certain things…

Have a great day y’all… its time for me to hit the hay…

Regards,

Bruce V. aka OASys1

12

With all due respect, preventing the close button is hardly the reason to migrate an Access application to .NET, and is not related to moving to SQL Server.

The cost of converting 50 forms and who knows how many reports and VBA code from an Access application to .NET would be tens of thousands of dollars. Add more for converting to SQL Server. Not compelling when the reason is for preventing the close button.

When is the technique not reliable? We use it all the time.

13

I wonder about putting a warning message box that says it you close using the X you will ruin the data. Then if somoene does they can be disciplined

14

You can’t do that in Microsoft Access. Well, you can, using the techniques Luke has pointed you to, but it’s a hack, it’s difficult, and it’s not always reliable.

To get that level of control over the entire application, you should migrate the “front end” to a separate application developed in Visual Basic, using Visual Studio. Your application can connect to a database, which can still be a Microsoft Access file; of course, as your application (and the number of users) grows, you can also migrate the “back end” to a more capable multi-user database such as Microsoft SQL Server (starting with the free Express version).

Michael S. Meyers-Jouan

15

This is described in our article: Disable the Microsoft Access Close Button to Prevent Users from Accidentally Closing Your Application

It’s part of our Microsoft Access Developer and VBA Programming Help Center