Tùy chọn
Pro Access cho em hỏi
- Pro Access cho em hỏi
-
Pro Access cho em hỏi
Cuong Servenet > 13-07-18, 11:21 AM
Có anh chị nào pro access cho em hỏi cách tạo các hàm, chương trình trong module.
để khi viết các chương trình nút bấm , xóa , chiều cao co dãn ...cho forms và report không vậy nhỉ?
Vì nếu 1 ứng dụng có đến vài trăm cái forms , vs report mà viết từng câu lệnh đóng mở cho các forms thì rất mất nhiều thời gian .và sẽ bị rắc rối nhìn code hoa cả mắt .
--> chỉ cần forms nó mở ra là các chương trình nút bấm vvv nó đã đc cài mặc định chạy.
Mong các pro chỉ giáo cho em vs ạ. -
RE: Pro Access cho em hỏi
tranthanhan1962 > 13-07-18, 01:08 PM
Nói chung, Access là lập trình hướng đối tượng. "các chương trình nút bấm" của bạn là các event Click_button, bạn buột phải đưa code vào event thì nó mới chạy được. Có thể dùng các phương pháp để xử lý giảm tải trong thiết kế như:
1/ Thiết kế form mẫu dùng chung có sẳn các code, và thiết kế tương tự sau đó dùng nó để phát triển thành các form riêng lẽ.
2/ Tạo các sub, function toàn cục sau đó tùy trường hợp thì gọi các sub và function này để nhẹ viết code.
Tóm lại có phần mềm thì có lệnh nó mới chạy, không lệnh thì khỏi chạy, cũng như có tiền thì mới shopping được
.
Một ứng dụng có vài mươi form là bở hơi tai rồi, vài trăm form có mà chết. Vấn đề là thiết kế sao cho 1 form có thể làm nhiều nhiệm vụ tương đương. Một chương trình lớn nếu khéo léo có thể chưa đầy 10 form, 10 report. Tôi chưa bao giờ thấy ai viết phần mềm (cả các công ty phần mềm trên thế giới viết đến 100 form & report). Ngay cả Hệ điều hành windows cũng chưa sử dụng đến 100 giao diện khác nhau
-
RE: Pro Access cho em hỏi
Cường Servenet SE > 14-07-18, 12:15 AM
(13-07-18, 01:08 PM)tranthanhan1962 Đã viết: Nói chung, Access là lập trình hướng đối tượng. "các chương trình nút bấm" của bạn là các event Click_button, bạn buột phải đưa code vào event thì nó mới chạy được. Có thể dùng các phương pháp để xử lý giảm tải trong thiết kế như:
1/ Thiết kế form mẫu dùng chung có sẳn các code, và thiết kế tương tự sau đó dùng nó để phát triển thành các form riêng lẽ.
2/ Tạo các sub, function toàn cục sau đó tùy trường hợp thì gọi các sub và function này để nhẹ viết code.
Tóm lại có phần mềm thì có lệnh nó mới chạy, không lệnh thì khỏi chạy, cũng như có tiền thì mới shopping được .
Một ứng dụng có vài mươi form là bở hơi tai rồi, vài trăm form có mà chết. Vấn đề là thiết kế sao cho 1 form có thể làm nhiều nhiệm vụ tương đương. Một chương trình lớn nếu khéo léo có thể chưa đầy 10 form, 10 report. Tôi chưa bao giờ thấy ai viết phần mềm (cả các công ty phần mềm trên thế giới viết đến 100 form & report). Ngay cả Hệ điều hành windows cũng chưa sử dụng đến 100 giao diện khác nhau
vậy mình nhóm em đang nhận dự án viết chương trình như vậy đó . tổng cộng 670 cái Forms + Report . chưa tính cả SQL nữa .
thời gian hoàn thành là 2 tháng , 1 tháng test chương trình.
Nếu mà ko dùng đc cách như em hỏi đó thì sẽ rất lâu
-
RE: Pro Access cho em hỏi
tt1212 > 14-07-18, 12:35 AM
Bạn tạo một module
Sau đó bạn viết các hàm
Ví dụ Muốn đóng form bạn viết
Mã PHP:Function dong(f as form)
docmd.f.close
end function -
RE: Pro Access cho em hỏi
tranthanhan1962 > 14-07-18, 11:26 AM
Thứ nhất: Khi phân tích chương trình bạn có phân tích đầy đủ chưa: hệ thống table là quan trọng nhất. SQL là tùy yêu cầu. Nếu các table có quan hệ thì xem lợi thế chi tách table cha cno hay để chung 1 table cái nào ưu thế hơn.
Thứ hai: Hệ thống form nhập liệu, có bao nhiêu nhóm tương đương (giải quyết bằng mỗi nhóm bằng 1 form, rồi thay đổi RecordSource hay copy ra từng form xử lý recordsource riêng), hệ thống form truy vấn có bao nhiêu nhóm tương đương (hoạt động bằng các checkbox, combobox, option group...thay đổi điều kiện xử lý hay từng form dialog xử lý riêng biệt. Report cũng vậy.
Tóm lại nếu phân tích kỹ thì 670 cái form kia có khi không còn là bao nhiêu.
Ví dụ: Nhập liệu kho hàng. Nếu theo các nghiệp vụ: Nhập mua, nhập nôi bộ, nhập hàng trả, xuất bán, xuất xử dụng, xuất hao hụt, xuất nôi bộ. Nếu căn cứ các nghiệp vụ sẽ có 7 table dữ liệu, 7 form nhập liệu, sau đó sẽ có một query union rồi thêm các select query xử lý tồn kho ...Trong khi đó chỉ cần tạo 1 table nhập xuất có thêm một field nghiệp vụ nhập xuất thì chỉ cần 1 form nhập liệu và không cần làm query union. Ví dụ thay vì tạo các form nhập liệu riêng lẽ như danh sách phòng ban, danh sách nhân viên, danh sách hàng hóa...Thì chỉ cần tạo một form rồi copy chỉnh sửa recordsource và các controls cho form khác hoạc chỉ sử dụng một form rồi tạo code đổi recordsource. Nói chung viết phần mêm không phải mỗi cái mỗi viết , mỗi design mà phải biết thừa kế những phần đã viết, chúc bạn thành công. -
RE: Pro Access cho em hỏi
ongke0711 > 14-07-18, 01:16 PM
(13-07-18, 11:21 AM)Cuong Servenet Đã viết: Vì nếu 1 ứng dụng có đến vài trăm cái forms , vs report mà viết từng câu lệnh đóng mở cho các forms thì rất mất nhiều thời gian .và sẽ bị rắc rối nhìn code hoa cả mắt .
--> chỉ cần forms nó mở ra là các chương trình nút bấm vvv nó đã đc cài mặc định chạy.
Tôi không biết ứng dụng bạn làm nó lớn như thế nào chứ mấy cái ứng dụng nhỏ nhỏ của tôi như: quản lý xe, quản lý văn phòng phẩm mà có mỗi nút Lưu, Đóng ở một số Form phải code khác nhau chứ không phải cứ mỗi "Docmd.Close" là xài chung hết được.
Vd:
- Ở một Form khi bấm Đóng thì phải kiểm tra lại: đã có sửa đổi gì trên form chưa, nếu có -> có cần lưu hay không lưu thông tin (Bound Form) rồi code xử lý nó để tránh thông tin tự động lưu vào table -> xong mới đóng nó.
- Nút Lưu: khi bấm Lưu cũng phải có code kiểm tra các trường trong form này có Null không, nếu có thì xử lý ra sao. Rồi trường hợp kiểm tra xem có phát sinh dữ liệu liên quan đến Record đang sửa chưa, nếu có rồi thì không được phép Lưu để tránh xung đột dữ liệu v.v..
Nói chung tuỳ khả năng code của bạn để có thể tái sử dụng lại các thủ tục, hàm chứ không có chuyện làm sẳn môt nút lệnh rồi chung cho tất cả các Form.
Ms Access đã có làm sẳn cho bạn là các Control: Textbox, Lable, Command button... đó là nhưng cái sẳn và có thể dùng chung còn code cho nó hoạt động như thế nào là tuỳ form, tuỳ ứng dụng mà bạn viết cho nó. -
RE: Pro Access cho em hỏi
Cường Servenet SE > 14-07-18, 05:15 PM
(14-07-18, 01:16 PM)ongke0711 Đã viết:
(13-07-18, 11:21 AM)Cuong Servenet Đã viết: Vì nếu 1 ứng dụng có đến vài trăm cái forms , vs report mà viết từng câu lệnh đóng mở cho các forms thì rất mất nhiều thời gian .và sẽ bị rắc rối nhìn code hoa cả mắt .
--> chỉ cần forms nó mở ra là các chương trình nút bấm vvv nó đã đc cài mặc định chạy.
Tôi không biết ứng dụng bạn làm nó lớn như thế nào chứ mấy cái ứng dụng nhỏ nhỏ của tôi như: quản lý xe, quản lý văn phòng phẩm mà có mỗi nút Lưu, Đóng ở một số Form phải code khác nhau chứ không phải cứ mỗi "Docmd.Close" là xài chung hết được.
Vd:
- Ở một Form khi bấm Đóng thì phải kiểm tra lại: đã có sửa đổi gì trên form chưa, nếu có -> có cần lưu hay không lưu thông tin (Bound Form) rồi code xử lý nó để tránh thông tin tự động lưu vào table -> xong mới đóng nó.
- Nút Lưu: khi bấm Lưu cũng phải có code kiểm tra các trường trong form này có Null không, nếu có thì xử lý ra sao. Rồi trường hợp kiểm tra xem có phát sinh dữ liệu liên quan đến Record đang sửa chưa, nếu có rồi thì không được phép Lưu để tránh xung đột dữ liệu v.v..
Nói chung tuỳ khả năng code của bạn để có thể tái sử dụng lại các thủ tục, hàm chứ không có chuyện làm sẳn môt nút lệnh rồi chung cho tất cả các Form.
Ms Access đã có làm sẳn cho bạn là các Control: Textbox, Lable, Command button... đó là nhưng cái sẳn và có thể dùng chung còn code cho nó hoạt động như thế nào là tuỳ form, tuỳ ứng dụng mà bạn viết cho nó.
đúng là như vậy 1 ứng dụng nó nhiều forms như vậy đâu chỉ đơn giản là mỗi cái docmd.close là xong đâu ạ. -
RE: Pro Access cho em hỏi
Cường Servenet SE > 14-07-18, 05:23 PM
(14-07-18, 11:26 AM)tranthanhan1962 Đã viết: Thứ nhất: Khi phân tích chương trình bạn có phân tích đầy đủ chưa: hệ thống table là quan trọng nhất. SQL là tùy yêu cầu. Nếu các table có quan hệ thì xem lợi thế chi tách table cha cno hay để chung 1 table cái nào ưu thế hơn.
Thứ hai: Hệ thống form nhập liệu, có bao nhiêu nhóm tương đương (giải quyết bằng mỗi nhóm bằng 1 form, rồi thay đổi RecordSource hay copy ra từng form xử lý recordsource riêng), hệ thống form truy vấn có bao nhiêu nhóm tương đương (hoạt động bằng các checkbox, combobox, option group...thay đổi điều kiện xử lý hay từng form dialog xử lý riêng biệt. Report cũng vậy.
Tóm lại nếu phân tích kỹ thì 670 cái form kia có khi không còn là bao nhiêu.
Ví dụ: Nhập liệu kho hàng. Nếu theo các nghiệp vụ: Nhập mua, nhập nôi bộ, nhập hàng trả, xuất bán, xuất xử dụng, xuất hao hụt, xuất nôi bộ. Nếu căn cứ các nghiệp vụ sẽ có 7 table dữ liệu, 7 form nhập liệu, sau đó sẽ có một query union rồi thêm các select query xử lý tồn kho ...Trong khi đó chỉ cần tạo 1 table nhập xuất có thêm một field nghiệp vụ nhập xuất thì chỉ cần 1 form nhập liệu và không cần làm query union. Ví dụ thay vì tạo các form nhập liệu riêng lẽ như danh sách phòng ban, danh sách nhân viên, danh sách hàng hóa...Thì chỉ cần tạo một form rồi copy chỉnh sửa recordsource và các controls cho form khác hoạc chỉ sử dụng một form rồi tạo code đổi recordsource. Nói chung viết phần mêm không phải mỗi cái mỗi viết , mỗi design mà phải biết thừa kế những phần đã viết, chúc bạn thành công.
Hệ thống bảng table thì bọn em phân tích rồi ạ,giờ chỉ là giải pháp làm sao để tối giản hóa code và ko mất nhiều thời gian nên em muốn hỏi về cái vấn đề đó ạ. 670 = from + report anh ơi from thì em gói gọn lại khoảng 250 cái main + sub , còn lại chủ yếu là report nhiều -
RE: Pro Access cho em hỏi
tranthanhan1962 > 14-07-18, 06:21 PM
Với yêu cầu như thế mà viết bằng access khả năng bị bị đứng máy cao đó. -
RE: Pro Access cho em hỏi
ongke0711 > 14-07-18, 06:59 PM
(14-07-18, 05:15 PM)Cường Servenet SE Đã viết: đúng là như vậy 1 ứng dụng nó nhiều forms như vậy đâu chỉ đơn giản là mỗi cái docmd.close là xong đâu ạ.
Biết vậy sao còn yêu cầu viết sẳn các lệnh đóng mở dùng chung làm gì nhỉ.
Còn nếu muốn dạng các thủ tục, hàm có thể tái sử dụng cho các form thì bạn có thể tham khảo bài tôi mới post có dùng hàm GetRecord để load dữ liệu cho unbound form dạng Single form. Hàm này có thể dùng chung cho các form nếu có thiết kế tương tự.
Link: http://thuthuataccess.com/forum/post-39412.html