A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Error traps, code residue & lanscape mode



 
 
Thread Tools Display Modes
  #1  
Old May 26th, 2004, 05:27 PM
Jim
external usenet poster
 
Posts: n/a
Default Error traps, code residue & lanscape mode

I recently had an exchange via this site, which generated
excellent advice, as follows:

Subject: Opening report from form
From: "Allen Browne"
Sent: 5/21/2004 11:12:57 PM

Use the WhereCondition of the OpenReport action to limit
the report to the
current record in the form.

This example assumes the form has a numeric field
named "ID" that uniquely
identifies the record to print. Use the code in the Event
Procedure for the
Click event of a command button named "cmdPrint".

Private Sub cmdPrint_Click()
Dim strWhere As String
If Me.Dirty Then 'Save first
Me.Dirty = False
End If
If Me.NewRecord Then 'Check there is a record to
print
MsgBox "Pick a record."
Else
strWhere = "[ID] = " & Me.ID
DoCmd.OpenReport "MyReport", acViewPreview, ,
strWhere
End If
End Sub

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org."

I have a few houskeeping type follow-up questions:

1. My VBA knowledge is weak. When I use the Access
command button wizard to create an "open report" button,
rather than the method set out above, the VB inlcudes
code as follows:
"Private Sub Open_Opening_Reports_Click()
On Error GoTo Err_Open_Opening_Reports_Click

Dim stDocName As String

stDocName = "OpenOpeningReports"
DoCmd.RunMacro stDocName

Exit_Open_Opening_Reports_Click:
Exit Sub

Err_Open_Opening_Reports_Click:
MsgBox Err.Description
Resume Exit_Open_Opening_Reports_Click

End Sub"

Should I be including language, such as that set out
above, regarding errors, or is the current language,
which works great, sufficient? (I'm leaning toward "if it
ain't broke . . . ")

2. After fumbling around with the command buttons for a
while, and deleting a number of failed attempts, I find
there is a fair amount of code residue, no longer related
to any button behind my forms--I realize this might seem
like a silly question-Should I delete this code or let it
be?

3. Finally, and I apologize for going outside this
forum's heading: I have some reports that are
sufficiently wide that they need to be viewed and printed
in landscape mode. For some reason, even after I save
them in that mode, they revert to portrait mode from time
to time--any idea why that is and how I can prevent it?

Thank you in advance.

Jim

  #2  
Old June 10th, 2004, 02:50 AM
Eric Cárdenas [MSFT]
external usenet poster
 
Posts: n/a
Default Error traps, code residue & lanscape mode

I have a few houskeeping type follow-up questions:

1. My VBA knowledge is weak. When I use the Access
command button wizard to create an "open report" button,
rather than the method set out above, the VB inlcudes
code as follows:
"Private Sub Open_Opening_Reports_Click()
On Error GoTo Err_Open_Opening_Reports_Click

Dim stDocName As String

stDocName = "OpenOpeningReports"
DoCmd.RunMacro stDocName

Exit_Open_Opening_Reports_Click:
Exit Sub

Err_Open_Opening_Reports_Click:
MsgBox Err.Description
Resume Exit_Open_Opening_Reports_Click

End Sub"

Should I be including language, such as that set out
above, regarding errors, or is the current language,
which works great, sufficient? (I'm leaning toward "if it
ain't broke . . . ")

2. After fumbling around with the command buttons for a
while, and deleting a number of failed attempts, I find
there is a fair amount of code residue, no longer related
to any button behind my forms--I realize this might seem
like a silly question-Should I delete this code or let it
be?

--------------------
Because VBA is an interpreted language, the less code there is the more
efficient it will be. However there is also the issue of lack of
experience. I would leave code as long as they work to your satisfaction.
Later on, when you gain experience, you can examine it and fine tune it.

Hope this helps,

--
Eric Cárdenas
Senior support professional

This posting is provided "AS IS" with no warranties, and confers no rights.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 09:06 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.