Replies

I felt a little embarrassed that you printed only once (1 or 2 pages depending on page setup I supposed). I tried it again and this is what I found:

Set CBarCtl = CBar.Controls.Add(Type:=msoControlButton)
With CBarCtl
.Caption = “Cetak”
.Style = msoButtonIcon
.TooltipText = “Mencetak maklumat yang dipaparkan”
(1) .OnAction = “=CetakLapor()”
(2) ‘ .OnAction = “=DoCmd.PrintOut”
.FaceId = 4
End With

Function CetakLapor()
(3) DoCmd.PrintOut acPages, 1
(4) ‘ DoCmd PrintOut
End Function

If I use line (1) and disable line (2), the printer only prints once irrespective of whether line (3) or line (4) is used.
If I disable line (1) and activate line (2), then the printer would print the report 3 times. Why?

My sincere thanks for looking into my codes, Charlotte.

I send the attached database again.

In trying to extract the portions of my program that prints the report, and then running the extracted database, I discovered a solution to my problem. In my codes, there is a command bar in the menu that print the active report using the code :

DoCmd.PrintOut

By default it prints all the pages in the report. I changed it to print only one page:

DoCmd.PrintOut acPages, 1

Now my program prints only a single page of the report. But I am still puzzled why DoCmd.PrintOut print out three pages of the same report. The error could be in my query or reports.

I send the extracted database over (Print3.mdb) with some data in the table in case you need it. Sorry that most of the user’s codes are in the native language. The report is about statistics of students of different ethnicity in different classes and of different years of studies.

Yes, I am the only one using the database so far. It hasn’t seen the light outside my desktop yet. Both the front- and back-end of the database are in the local computer. Essentially I worked in a non-networked environment during the codes and interface writing stage.
The records with bad autonumber do have memo fields – but what is the relationship between the error and memo fields?

As far as I can recall, the desktop I am using suffers no crashes during the developmental stage of my database. Unlikely the record pointer wasn’t updated by the computer because of crashes.

As you suggested, I will go back to my codes again. My back-end database has a main table related to another two tables, with the autonumber as the primary connecting key. In the codes, the three tables are related using SQL. This could be the cause of error since you mentioned it.

I really hope the error is in my codes else my confidence in Access would be dented.

Yes, I have 1302 records in the table of my sample database. The table has autonumber ID. It is a split file, called by a main database file. I didn’t compact/repair the sample database often during testing. (But I did run Compact/Repair database after I discovered the error, but the error persisted even after compact/repair.) When I said the new record was 787 instead of 1302, I meant the record pointer (?) was reset to 787 instead of the expected 1302 for new record. As for whether all my MS Office components were SR1, I access Help->About Microsoft windows for all my Office components, they show version 9.0.4402 SR-1. This is the only clue that I have to indicate my Office is of SR-1 version.

Initially I never expected the error to occur as I suspected something wrong with my codes (which ran correctly before the error). With the error, I couldn’t go to a new record. After hours of modifying my codes without success, then it only dawned on me to check the table in the split database. That was the moment of truth.

I think Charlotte is right – there is no way to make A2K forms IME-aware. Microsoft had only in mind to make IME a word-processing adjunct to Word for East Asian Language input and making A2K forms respond to IME was just too much trouble.

I manage to find a convoluted solution to my own problem – input Chinese characters in English A2K forms. I used a Chinese front processors called Chinese Star 2001 (which is compatible with MS Office 2K) made by a company in China and marketed by SunTendy America Inc. Here are the procedures I used for those who are interested:

(1) Run Chinese Star 2001 (CStar) first before A2K.

(2) Start A2K and activate a form in design view. In the properties pop-up of the control boxes, an additional property called IME Mode will be inserted. The IME mode has three options : No Control, IME ON, IME OFF. Just leave the property with the default option – No Control. I suspect the IME on/off properties can be used in VBA codes. But since CStar has to be in memory before Chinese characters can be entered, I see no necessity to incorporate it in codes. More importantly, incorporating these properties in codes will halt A2K when CStar isn’t running in the background.

(3) Since I need to input Chinese names, I use a textbox to get user’s input. CStar comes with many nice fonts which are not displayable once CStar is exited. Hence I don’t use any of the CStar fonts supplied. Instead I choose the MS Song font (mssong.tff) by Microsoft (used by IE5 to display web sites using Simplified Chinese), which supports code page 936 : Simplified Chinese characters for PRC & Singapore, and which is displayable by CStar too. In this way, I can view Chinese characters together with other English input in the same A2K form without CStar. Note that CStar is still needed for Chinese characters input.

Any caveat? So far there is one. If CStar is running and a controlbox with date input is edited, it will automatically be displayed in the traditional yy/mm/dd Chinese calendar format. However, if no editing is done or if CStar isn’t running, the date format displayed follows the input mask or the format() in codes. I wonder if anyone has any idea how I can make the displayed date different from the yy/mm/dd format forced upon the user by CStar.

I understand there are many other Chinese/Japanese/Korean (CJK) front processors available, like UnionWay and TwinBridge (by US companies), and NJStar (by an Australian company). I have only experimented only with CStar 2001 and it fulfills my need, albeit in a round-about way.

My sincere thanks to Charlotte, WendelB and MarkJ for giving me pointers in searching for a solution to my problem.

I can’t recall where did I read this, or if what I read was meant for A2K or A2002. But I remembered reading that internally VBA represents every string in Unicode format, and has to convert the string to ANSI if Unicode isn’t used. That caused me make the statement that MSO 2K can understand Unicode.

My requirement is very “simple”. I want to set up a textbox in Access whereby when it is in focus, the IME is automatically turned on for input of East Asian characters (names of customers in Chinese), and when it loses its focus, the IME is disabled, and normal input in English is enabled. I read that MSO 2K understands unicode, I thought it is a matter of tweaking before one can input East Asian characters in its testbox. Thanks for your reply.

I discovered by accident and after several trials that the MDE does change its startup properties as dictated by the conditional compilation – the MDE has to be bypassed by using Shift, and then allowed to run the program once before the changed startup properties can be activated. I don’t know why it behaved this way. If the MDE was run immediately it was made and after exiting from Access, the startup properties weren’t changed as expected from the conditional compilation.

I forgot to mention – the sub ChangeProperty() was extracted from the VBA Help file.

I used the compiler directive as it was suggested in the Help file It worked when I wanted to change from docmd.close (#Const conVersiMDE = False) in MDB to docmd.quit when I made it into a MDE (#Const conVersiMDE = True). I was using a const before I used #const. Both worked well.

I deleted the conditional compiler directive and just left the codes like belows:

—————————–
Sub SetStartupProperties()

Const DB_Text As Long = 10
Const DB_Boolean As Long = 1

ChangeProperty “AllowShortcutMenus”, DB_Boolean, False
ChangeProperty “AllowBuiltinToolbars”, DB_Boolean, False
ChangeProperty “AllowFullMenus”, DB_Boolean, False
ChangeProperty “AllowSpecialKeys”, DB_Boolean, False
ChangeProperty “AllowBypassKey”, DB_Boolean, False
Application.VBE.MainWindow.Visible = False

End Sub
———————————

Still the Startup properties didn’t change, and the Shift bypass key happily displayed my database windows on startup and the shortcut menu could be popped up by right-clicking.

I am curious why it works in MDB and not in MDE. Is it my mistake or a designed feature of A2K ?

Based on the lead given by HansV, I imported the modules basRegistry and basCommon from Chapter 17 of the book “Access 2002 Desktop Developer’s Handbook” by Litwin, Getz, and Gunderloy (Sybex 2001) to change the key data of the key value “A.hlp” of subkey “SoftwareMicrosoftWindowsHelp” of the root key HKEY_LOCAL_MACHINE. (The codes work in A2K as well as A2002.)

When my program starts, it checks if A.hlp is in the mdb directory. If it is, then it will access the registry HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsHelp to look for the key value A.hlp to check if the key data is the same as the directory of the mdb. If it is, then exit sub; else modify the key data to that of the mdb directory. If A.hlp isn’t in the same same diretory of the mdb file, then nothing is done as it is possible that the help file A.hlp could be in the Access default directory and the user installed the mdb somewhere else.

The scheme works. Now the mdb and the associated help file can be moved to anywhere and still the user is able to access the help file by menu or by F1 short-cut. Just to be sure, is there any caveat that I am not aware of to the scheme above?

Still I think the scheme above is an overkill just to make sure the mdb and the hlp files can be moved together anyway in the desktop without the alarming “The file help is not available” message to an unsuspected user. Does anyone has a simpler way of achieving the same thing?

Thanks HansV. I understand the first part when I looked at the Helpfile property of my forms/reports. I personally put it there myself without realizing that is how Access knows the name of my help file.

The second part still puzzles though. I actually use Application.CurrentProject.Path plus the help file name in
With obj
hWnd = .hWnd
strHelpFile = Application.CurrentProject.Path & “” & “A.HLP”
lngContext = .HelpContextId
End With

When I move the help file and the Access mdb together to another folder, my program can access the help file when ShowHelpAPI() is directly called. The problem is that the help key F1 cannot access the help file anymore (which it did in its original location). I suppose when F1 is pressed, Access looks into the folder of the original help file in the registry. Am I right? Is there any other method where the help shortcut F1 can recognise the new location of my help file as indicated in Application.CurrentProject.Path & “” & “A.HLP”
without resorting to Regedit? I think it is a bad design on the part of Windows if I have to resort to editing the registry just to access the help file when it is moved to another location.

I agree with you Douglas, and reliability or the lack of it in using CurDir() caused me intermittent problem.

Thanks Dottie. I use Application.CurrentProject.Path to get the path to the database.Thanks too to Tim and Charlotte for helping me.