عدم عمل بعض الوحدات النمطيه في اكسس 2010-2007

اخي الفاضل انا حددت سؤالي افتح الاوامر البرمجيه للفورم او افتح الوحدات النمطيه مره في الاكسس2003 ومره في الاكسس 2010 وشوف الفرق

انا قمت بحذف اوامر الازرار لعد اهميتها وحتى لا اعقد الامر ......... اما اذا اردت الفورم كامل باوامره .......... اتفضل بس لا تسال ما هذا

عندي سوال وين خبراء المنتدى (واقفين في الثورات؟؟؟؟؟؟؟؟؟)

db1.rar

لا اعتقد ان هناك مشكلة بالوحدات النمطية اخى

عموما يجب ان تحدد المشكلة بالضبط حتى يمكن للاخوة المساعدة

ما اجده قد يتسبب فى خطأ هو كود التصدير او الاستيراد من و الى الاكسيل

    DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel8, "ÕÑÝ", Me.myPath & "\" & Format(Date, "dd-mm-yyyy") & "\" & "ÕÑÝ" & ".xls", True

عدل هذا الكود بدون تحديد نوع ملف الاكسيل

ان شاء الله يعمل معك الملف

DoCmd.TransferSpreadsheet acExport, , "ÕÑÝ", Me.myPath & "\" & Format(Date, "dd-mm-yyyy") & "\" & "ÕÑÝ" & ".xls", True

اخي الفاضل Abo_Yossof الكود صحيح لانه يعمل في اكسس 2003 ولكن لا يعمل في اكسس 2010

هذا اولا

اما عن المشكله فليست هنا ولكن عند فحص اي من الوحدات النمطيه في البرنامج بواسطه COMPILE في نافذه الفجوال اكسس تظهر المشاكل فقط فقط فقط في اكسس 2010 اما عند فحص الوحدات النمطيه في اكسس 2003 يطلع كل شئ تمام واكرر الفحص بواسطه COMPILE في نافذه الفجوال اكسس

aecc كتب:

اخي الفاضل Abo_Yossof الكود صحيح لانه يعمل في اكسس 2003 ولكن لا يعمل في اكسس 2010

هذا اولا

اما عن المشكله فليست هنا ولكن عند فحص اي من الوحدات النمطيه في البرنامج بواسطه COMPILE في نافذه الفجوال اكسس تظهر المشاكل فقط فقط فقط في اكسس 2010 اما عند فحص الوحدات النمطيه في اكسس 2003 يطلع كل شئ تمام واكرر الفحص بواسطه COMPILE في نافذه الفجوال اكسس

يمكنك ان تحدد الاسطر التى يحدث عندها الخطأ عند عمل compile

و رسالة الخطأ التى تظهر حتى تسهل على من يريد مساعدتك

فليس الجميع يستخدم 2010

abdalla89 اخي والله اسف لم اقصد الحده قد يكون انفعال ههههههههههههههه

ثانيا العبارة التي تظهر بلون احمر عند عمل compile هي مثلا:

Private Declare Function SHGetPathFromIDList Lib "shell32.dll" Alias "SHGetPathFromIDListA" _

(ByVal pidl As Long, ByVal pszPath As String) As Long

او العبارة التالية:

Declare Function SetTimer Lib "user32" (ByVal hwnd _

As Long, ByVal nIDEvent As Long, ByVal uElapse _

As Long, ByVal lpTimerFunc As Long) As Long

Declare Function KillTimer Lib "user32" _

(ByVal hwnd As Long, ByVal nIDEvent As Long) _

As Long

او العبارة التالية:

Public Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long

ماذا افعل :blink: :wacko:

العبارة التي تظهر بلون احمر عند عمل compile هي مثلا:

Private Declare Function SHGetPathFromIDList Lib "shell32.dll" Alias "SHGetPathFromIDListA" _

(ByVal pidl As Long, ByVal pszPath As String) As Long

او العبارة التالية:

Declare Function SetTimer Lib "user32" (ByVal hwnd _

As Long, ByVal nIDEvent As Long, ByVal uElapse _

As Long, ByVal lpTimerFunc As Long) As Long

Declare Function KillTimer Lib "user32" _

(ByVal hwnd As Long, ByVal nIDEvent As Long) _

As Long

او العبارة التالية:

Public Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long

نفس المشكله واجهتني وبحثة في موقع اوفيس

وكانت هذه الاجابة

قامت جمل Declare بتمكين تعليمات VBA البرمجية لاستدعاء Win32 API وملفات DLL خارجية أخرى. قبل هذا الإصدار، لم يكن نوع بيانات المؤشر متوفرًا لـ VBA، لذلك استخدم المطوّرون نوع البيانات "الطويلة" للمحافظة على قيم المؤشر. وبسبب عدم زيادة حجم نوع البيانات "الطويلة" في أنظمة إصدار 64 بت، على عكس المؤشرات، فقد تتسبّب جمل Declare الموجودة في حدوث سلوك غير متوقع يُنتج التعطّل عنه.

الحل: يجب أن تخضع جمل Declare للمراجعة والتعديل كما تقتضي الحاجة مع استخدام نوع بيانات المؤشر الجديد في VBA، وهو LongPtr، ونوع البيانات الرقمية الجديد لإصدار 64 بت في VBA، وهو LongLong.
الوسيطات وقيم الإرجاع ليست وحدها التي تحتاج إلى مراجعة، بل أيضًا أية قيم UDT تم تمريرها إلى API أو خارجها. بعد تنفيذ ذلك، يجب إضافة سمة PtrSafe إلى جملة Declare لكي يقبلها محول VBA البرمجي لإصدار 64 بت.

فكيف يتم ذلك

فهل ممكن ان يفيدنا احد لحل هذه المشكله

وجزاكم الله خيرا

تم حل المشكله ولله الحمد

لمعرفة طريقة الحل

راجع الرابط التالي :