Nesting error foxpro ошибка

Вот спасибо! Не знал об этом.

Запускаю форму так:

Для удобства, решил что имя файла, свойство Form.NAME и имя объектной переменной будут иметь одинаковое значение. В конкретном случае это ‘Spr_Unit’. Насчёт более чем одного запуска формы — логикой программы эта возможност исключена.

Грид лежит на форме, которая является экземпляром пользовательсого класса, наследника класса Form. И он удачно «находится».

Исправлено 3 раз(а). Последнее : Dutch, 08.11.12 15:59

И если ты так тщательно контролируешь точку запуска форм, то зачем делать это через ПЕРЕМЕННЫЕ? Ещё раз — если твоя форма не модальная, то после запуска код пойдёт дальше, дойдёт до конца модуля (процедура это, функция, метод — не суть важно) и там переменная перестанет существовать.
Лучше уж тогда организовать СВОЮ коллекцию/массив для хранения ссылок на запускаемые формы (у «своего» есть плюсы по сравнению с встроенными _VFP/_SCREEN.Forms — например можно не все формы туда помещать, можно явно задавать свой «идентификатор для поиска экземпляра»). И, естественно, обеспечить должную область видимости для этой коллекции/массива (банально PUBLIC, или добавить её к _SCREEN или к «своему объекту приложения goApp»).
100500 private переменных непонятно когда создаваемых и непонятно когда уничтожаемых (или приобретающих в качестве значения .NULL. — если форму закрыли) до добра не доведут. «непонятно когда» — в смысле использующего их потом кода. Например из меню НЕЛЬЗЯ безопасно обратиться к такой переменной, из некоего метода базового класса — тоже.

Кстати, сама идея обращаться к объектам формы «снаружи» дурно попахивает. С объектами формы должна работать сама форма — а для её методов всегда доступен This/ThisForm — и никаких «переменных» не нужно.

Жесть. Назачем тогда вообще это меню надо

Источник

Nesting error in foxpro

Вот спасибо! Не знал об этом.

Запускаю форму так:

Для удобства, решил что имя файла, свойство Form.NAME и имя объектной переменной будут иметь одинаковое значение. В конкретном случае это ‘Spr_Unit’. Насчёт более чем одного запуска формы — логикой программы эта возможност исключена.

Грид лежит на форме, которая является экземпляром пользовательсого класса, наследника класса Form. И он удачно «находится».

Исправлено 3 раз(а). Последнее : Dutch, 08.11.12 15:59

Сообщений: 34580
Дата регистрации: 28.05.2002

И если ты так тщательно контролируешь точку запуска форм, то зачем делать это через ПЕРЕМЕННЫЕ? Ещё раз — если твоя форма не модальная, то после запуска код пойдёт дальше, дойдёт до конца модуля (процедура это, функция, метод — не суть важно) и там переменная перестанет существовать.
Лучше уж тогда организовать СВОЮ коллекцию/массив для хранения ссылок на запускаемые формы (у «своего» есть плюсы по сравнению с встроенными _VFP/_SCREEN.Forms — например можно не все формы туда помещать, можно явно задавать свой «идентификатор для поиска экземпляра»). И, естественно, обеспечить должную область видимости для этой коллекции/массива (банально PUBLIC, или добавить её к _SCREEN или к «своему объекту приложения goApp»).
100500 private переменных непонятно когда создаваемых и непонятно когда уничтожаемых (или приобретающих в качестве значения .NULL. — если форму закрыли) до добра не доведут. «непонятно когда» — в смысле использующего их потом кода. Например из меню НЕЛЬЗЯ безопасно обратиться к такой переменной, из некоего метода базового класса — тоже.

Кстати, сама идея обращаться к объектам формы «снаружи» дурно попахивает. С объектами формы должна работать сама форма — а для её методов всегда доступен This/ThisForm — и никаких «переменных» не нужно.

Сообщений: 34580
Дата регистрации: 28.05.2002

Жесть. Назачем тогда вообще это меню надо

Источник

Nesting error in foxpro

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

FOR XX = 1 TO 15 STEP 1
*
*
*
NEXT XX && rarely
why this happens ?

Answers

If you try to compile this you get such a compile error:

For xx = 1 to 10
If xx=1
Else
Next xx

What’s missing is no not NEXT or ENDFOR, but ENDIF. So look out for any nesting error in code inside the loop.

Olaf Doschke — TMN Systemberatung GmbH http://www.tmn-systemberatung.de

• Proposed as answer by Ed Price — MSFT Microsoft employee Saturday, December 13, 2014 9:38 AM
• Marked as answer by Ed Price — MSFT Microsoft employee Monday, March 16, 2015 8:23 AM

The above replicates the FOR loop you are using.

I have not received any errors after numerous runs of the above.

One thing to point out is that the NEXT ii statement is technically incorrect.

It should be just NEXT — so

The English Bob

• Proposed as answer by Ed Price — MSFT Microsoft employee Saturday, December 13, 2014 9:38 AM
• Marked as answer by Ed Price — MSFT Microsoft employee Monday, March 16, 2015 8:23 AM

What means «rarely»? Are you able to reproduce this error? If not then you cannot fix it probably. And I can say it is either a bug in your code or in VFP itself.

NEXT can generate Nesting error if the FOR command fails or if the VFP forgets about it etc. etc.

Did you try the VFP Compiler from baiyujia ? Does the bug appears in compiled code?

• Edited by Pavel Celba Thursday, October 30, 2014 11:34 PM link added
• Proposed as answer by Ed Price — MSFT Microsoft employee Saturday, December 13, 2014 9:39 AM
• Marked as answer by Ed Price — MSFT Microsoft employee Monday, March 16, 2015 8:23 AM

I remembered and found a tek-tips thread I wrote about having ERROR 96 «Nesting Error» at runtime.

The problem was never resolved, but in my case remained a one time only error. If ou have his rarely, but still too often, the best thing you may do is rewrite that passage to something else. Perhaps you put the large CASE statement into a procedure or other method.

Taken from the tek-tips thread, one thinkable way to have this error at runtime is causing the issue mentioned in the help, an EXIT outside of a loop.

This here compiles and errors at runtime with error 96:

Nevertheless, this wasn’t my problem, nor do I think you do something causing an error by macro substitution.

It’s strange enough, that there is a native error number 96, while this rather is an error not thinkable at runtime, if there is no nesting error found at compile time. And compile time errors don’t have an error number, they are output and in case they’re fatal they stop compilation.

Источник

Nesting error in foxpro

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

FOR XX = 1 TO 15 STEP 1
*
*
*
NEXT XX && rarely
why this happens ?

Answers

If you try to compile this you get such a compile error:

For xx = 1 to 10
If xx=1
Else
Next xx

What’s missing is no not NEXT or ENDFOR, but ENDIF. So look out for any nesting error in code inside the loop.

Olaf Doschke — TMN Systemberatung GmbH http://www.tmn-systemberatung.de

• Proposed as answer by Ed Price — MSFT Microsoft employee Saturday, December 13, 2014 9:38 AM
• Marked as answer by Ed Price — MSFT Microsoft employee Monday, March 16, 2015 8:23 AM

The above replicates the FOR loop you are using.

I have not received any errors after numerous runs of the above.

One thing to point out is that the NEXT ii statement is technically incorrect.

It should be just NEXT — so

The English Bob

• Proposed as answer by Ed Price — MSFT Microsoft employee Saturday, December 13, 2014 9:38 AM
• Marked as answer by Ed Price — MSFT Microsoft employee Monday, March 16, 2015 8:23 AM

What means «rarely»? Are you able to reproduce this error? If not then you cannot fix it probably. And I can say it is either a bug in your code or in VFP itself.

NEXT can generate Nesting error if the FOR command fails or if the VFP forgets about it etc. etc.

Did you try the VFP Compiler from baiyujia ? Does the bug appears in compiled code?

• Edited by Pavel Celba Thursday, October 30, 2014 11:34 PM link added
• Proposed as answer by Ed Price — MSFT Microsoft employee Saturday, December 13, 2014 9:39 AM
• Marked as answer by Ed Price — MSFT Microsoft employee Monday, March 16, 2015 8:23 AM

I remembered and found a tek-tips thread I wrote about having ERROR 96 «Nesting Error» at runtime.

The problem was never resolved, but in my case remained a one time only error. If ou have his rarely, but still too often, the best thing you may do is rewrite that passage to something else. Perhaps you put the large CASE statement into a procedure or other method.

Taken from the tek-tips thread, one thinkable way to have this error at runtime is causing the issue mentioned in the help, an EXIT outside of a loop.

This here compiles and errors at runtime with error 96:

Nevertheless, this wasn’t my problem, nor do I think you do something causing an error by macro substitution.

It’s strange enough, that there is a native error number 96, while this rather is an error not thinkable at runtime, if there is no nesting error found at compile time. And compile time errors don’t have an error number, they are output and in case they’re fatal they stop compilation.

Источник

Nesting error in foxpro

Сообщений: 212
Откуда: Волгодонск
Дата регистрации: 25.10.2010

Такие дела: хочу определить присутствует ли на форме грид. Есть название формы которое хранится в FormName. Делаю это так:

Если условие IF выполняется при Первой итерации, то MESSAGEBOX отрабатывается корректо и покидаем цикл. Если же при первой итерации мы не попадаем внутрь IF, то на комманде ENDFOR появляется ошибка «Nesting error».

Если же указываем имя формы явно, то ошибка «Nesting error»не появляется.

Исправлено 4 раз(а). Последнее : Dutch, 07.11.12 20:36

Ох уж эти ма. ма. мааакросы.
И как люди программируют на языках где их нет?

«Название формы» (кстати, что именно ты под этим понимаешь — такого термина НЕТУ в фоксе. Есть имя файла формы — т.е. MyForm.scx, и есть свойство формы Name — например frmMyTestForm) никак не связано с переменной — объектной ссылкой на созданный экземпляр формы. Да, по умолчанию команда DO FORM создаёт Private переменную с именем аналогичным имени файла формы (т.е. MyForm для этого примера) — но вся соль в том, что эта переменная Private, а значит код запросто может выйти за ту область видимости где эта переменная существует, ну или же эта переменная будет явно перекрыта другой, одноименной.
Вообще ПОДОБНЫЕ ссылки на исполняющиеся формы — дурной тон. Уж лучше использовать _VFP.Forms(«frmMyTestForm»), или даже цикл обхода по _VFP.Forms/_SCREEN.Forms, т.к. может быть запущено много экземпляров одной и той же формы.

Сообщений: 212
Откуда: Волгодонск
Дата регистрации: 25.10.2010

Вот спасибо! Не знал об этом.

Запускаю форму так:

Для удобства, решил что имя файла, свойство Form.NAME и имя объектной переменной будут иметь одинаковое значение. В конкретном случае это ‘Spr_Unit’. Насчёт более чем одного запуска формы — логикой программы эта возможност исключена.

Грид лежит на форме, которая является экземпляром пользовательсого класса, наследника класса Form. И он удачно «находится».

Исправлено 3 раз(а). Последнее : Dutch, 08.11.12 15:59

И если ты так тщательно контролируешь точку запуска форм, то зачем делать это через ПЕРЕМЕННЫЕ? Ещё раз — если твоя форма не модальная, то после запуска код пойдёт дальше, дойдёт до конца модуля (процедура это, функция, метод — не суть важно) и там переменная перестанет существовать.
Лучше уж тогда организовать СВОЮ коллекцию/массив для хранения ссылок на запускаемые формы (у «своего» есть плюсы по сравнению с встроенными _VFP/_SCREEN.Forms — например можно не все формы туда помещать, можно явно задавать свой «идентификатор для поиска экземпляра»). И, естественно, обеспечить должную область видимости для этой коллекции/массива (банально PUBLIC, или добавить её к _SCREEN или к «своему объекту приложения goApp»).
100500 private переменных непонятно когда создаваемых и непонятно когда уничтожаемых (или приобретающих в качестве значения .NULL. — если форму закрыли) до добра не доведут. «непонятно когда» — в смысле использующего их потом кода. Например из меню НЕЛЬЗЯ безопасно обратиться к такой переменной, из некоего метода базового класса — тоже.

Кстати, сама идея обращаться к объектам формы «снаружи» дурно попахивает. С объектами формы должна работать сама форма — а для её методов всегда доступен This/ThisForm — и никаких «переменных» не нужно.

Сообщений: 212
Откуда: Волгодонск
Дата регистрации: 25.10.2010

Жесть. Назачем тогда вообще это меню надо

Источник

Adblock
detector

Article: Q192081
Product(s): Microsoft FoxPro
Version(s): WINDOWS:5.0,5.0a,6.0
Operating System(s): 
Keyword(s): 
Last Modified: 13-AUG-1999

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft Visual FoxPro for Windows, versions 5.0, 5.0a, 6.0 
-------------------------------------------------------------------------------

SYMPTOMS
========

Using the Printer button on the Visual FoxPro Standard toolbar while a report is
in Preview mode causes the following error to occur:

  Report contains a nesting error.

RESOLUTION
==========

- Select the Printer icon on the Print Preview toolbar instead of the Printer
  icon on the Visual FoxPro Standard toolbar.

  -or-

- Add a NOWAIT clause to the end of the REPORT...PREVIEW command.

STATUS
======

Microsoft is researching this problem and will post new information here in the
Microsoft Knowledge Base as it becomes available.

MORE INFORMATION
================

Steps to Reproduce Behavior
---------------------------

1. Create a quick report with a table and save the report as MyRpt.

2. Run the following code in Command window:

        USE <tablename>
        REPORT FORM myRpt PREVIEW

3. When the Report Preview window opens, click the Printer button on the Visual
  FoxPro Standard toolbar, not the printer button on the Print Preview toolbar,
  to print the report and you see the following error message appear:

  Report contains a nesting error.

If a report is being edited using the Report Designer, then the error message
does not occur when that report is printed, as outlined in this article.

Additional query words: kbVFp500a kbVFp500 kbVFp600 kbPrinting kbReportWriter

======================================================================
Keywords          :  
Technology        : kbVFPsearch kbAudDeveloper kbVFP500 kbVFP600 kbVFP500a
Version           : WINDOWS:5.0,5.0a,6.0
Issue type        : kbprb
Solution Type     : kbpending

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED «AS IS» WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 1986-2002.