Form Designer problem (OpenInsight 32-bit Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== Form Designer problem (OpenInsight 32-bit Specific) ====
=== At 31 MAY 2003 10:21:52AM Bob Silverstein wrote: ===
 
{{tag>"OpenInsight 32-bit Specific"}}
 
<QUOTE>
I am developing a form and have been testing it successfully.  Without any obvious warning, Form Designer can no longer open the form.  I get a Windows message that something is wrong with formdes.exe and asks me to send it to Microsoft.  Other forms are okay and this bad form actually executes just fine!



Any ideas as to the problem or how to debug it?



I saw a reference to corrupted system indeces.  Might that be a clue?



"Re: Corrupted Repository Indexes on Upgrade 3.7.5 to 4.0.2 (Richard Guise)"
</QUOTE>
----

=== At 01 JUN 2003 06:57PM Paul Rule wrote:  ===

<QUOTE>Bob, I suspect a corrupt version of the source window which causes the form designer to crash while trying to load it.

The reason it runs ok is that the executable version is separate.

The source for the form is in SYSREPOSWINS, the executable version is in SYSREPOSWINEXES.

</QUOTE>

----

=== At 01 JUN 2003 09:25PM Bob Silverstein wrote:  ===

<QUOTE>That makes sense Paul but how would you fix it?

</QUOTE>

----

=== At 02 JUN 2003 12:00AM Richard Hunt wrote:  ===

<QUOTE>Bob, you are asking a very hard question. Maybe if you look at the "OIWIN_EQUATES" row in the "SYSPROCS" table, that might help.



First I would check the "SYSREPOSWINS" table for corruption (LH verify in the database manager). Then I would check the actual row in the "SYSREPOSWINS" table for corruption.



The "OIWIN_EQUATES" explains that the row is @RM delimited into 4 parts. Each part is explained in the "OIWIN_EQUATES". Maybe after careful examination you can find the problem. If not... well at lease you kinda have a mapping of what the window had and possibily using that you can recreate that window.



Be careful because saving or test running that window within the form designer could cause you to loose any code you have for events or menus.



I would be trying to find out what really is causing your form designer to fail otherwise you could start loosing more and more forms.

</QUOTE>

----

=== At 02 JUN 2003 04:18AM Oystein Reigem wrote:  ===

<QUOTE>Bob,



It might be a corrupted control. If it is you might be able to salvage most of your window by opening it (opening the relevant SYSREPOSWINS row) in System Editor and delete some of the content.



To be on the safe side you should make a copy of your system before you start surgery on your window.



When you open the SYSREPOSWINS row in System Editor you'll see a lot of lines. At each @FM in the SYSREPOSWINS row there will be a new line. You'll see

- a first line with a number

- a second line with a number

- a third line starting with a ÿ (@RM) some window data and continuing with data for the first control

- many lines - one for each of the remaining controls

- a line towards the end starting with ÿMENU

- some last line with data on events.

So there will be this large chunk of lines with essentially one line per control.



There might be additional line breaks because of two reasons:



Firstly, the System Editor might display some lines broken because of their length (] 1024 or something). In my windows it happens with the MENU line.



Secondly, any CR+LF in the window data will show as a line break. In practice this happens with text controls where you have caused an explicit line break in the control's text by hitting the Enter key. I don't know if you ever do that but I sometimes do, when I have a text control displaying text across several lines, and I want to have the final say over the linewise formatting of the text. Such line breaks will be converted to @FMs when you save the row, and corrupt the window. The workaround is to delete the line break and put it in later in Form Designer.



Now that you know all this you can do a round of trial and error where you take out some controls, leave the rest, save, and reopen the window in Form Designer, until you've narrowed down the problematic control(s). Of course you ought to make a copy of the row first so you can start from scratch each time. (I haven't given details about the first control, but hopefully that one is OK.)



- Oystein -





</QUOTE>

----

=== At 02 JUN 2003 08:29AM Bob Silverstein wrote:  ===

<QUOTE>Making progress.



Following up on Richard's suggestion, SYSREPOSWINS is not corrupt.  Looks like Oystein's ideas are helping.  I did indeed have a number of text boxes with multiple lines and these were obvious in System Editor.  I removed some of the text controls and could read the form into Form Designer normally (less those text boxes, of course). 



However, I also noticed that the form had over 66K characters before editing.  Upon removing moving some of those controls, the size came down to about 64K.  I wonder if forms are still stuck to the 64K limitation.  Any comment?

</QUOTE>

----

=== At 02 JUN 2003 10:56AM Richard Hunt wrote:  ===

<QUOTE>Bob,



Just want to let you know that the largest size I have is 16k. I used the sentence...



RUN RLIST "LIST SYSREPOSWINS BY-DSND SIZE SIZE",1



Maybe someone else can prove or disprove your theory.

</QUOTE>

----

=== At 02 JUN 2003 11:44AM Sean FitzSimons wrote:  ===

<QUOTE>Bob,



Yes there is still a 64K limit on the SYSREPOSWINS records.



Sean FitzSimons

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=814805F5C282DC7F85256D37004EE850|View this thread on the  forum...]]