• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • C0176: Badly ordered TYPE and VARIABLE declarations.

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (5)

Resolved C0176: Badly ordered TYPE and VARIABLE declarations.

  1. How-to
0
Votes
Undo
  1. Olan Knight
    Olan Knight
  2. PowerBuilder
  3. Wednesday, 17 March 2021 19:37 PM UTC

PB2019R3, b2670
Windows 10, 64 bit platform

I have two separate targets. Both are PB2019R3 apps.
I copied the PBL from target A into target B before starting.

In target A, tabpage 1 regenerates successfully, open in EDIT SOURCE, add a space, save, and it compiles successfully.

In target B, tabpage 1 regenerates successfully, open in EDIT SOURCE, add a space, save, and it fails the compile with the following error:

 ---------- Compiler: Errors   (2:31:28 PM)
icabs_cfg.pbl(u_cfg_tabpg_tiered_pricing_plans_maint).18: Error       C0176: Badly ordered TYPE and VARIABLE declarations. Is this modified exported source?
 ---------- Finished Errors   (2:31:28 PM)

 

What in the world is going on?

IDE: registrationfree use of ActiveX-Controls - Us...
Responses (5)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 17 March 2021 23:07 PM UTC
  2. PowerBuilder
  3. # 1

Auch! I have this very same thing happening to one of my tabpage userobjects which inherits from another one. it's been bugging me for 5 years now.
Every time when I forget about it and edit the source code, I get the exact same error and the only way to get around it, is by physically copying an older version by dragging it from the old pbl to the new pbl in the library painter. Then do a getlatest from source control. (simply getting the latest version from source control won't fix the problem, you first have to copy an older version physically into the library. Exporting and importing won't work either).
Don't forget to do an Optimize of that library too.

I can edit the object and save it without problems, but when editing the source and doing a simply change like adding a space somewhere in a comment, it's screwed again.
The other day I tried to get rid of this error by re-creating the ancestor from scratch, copy the code from the failing object step by step. After each copy of the code, edit the source of the new object add a space, delete the space and try to save. It all went well for some time, until suddenly the error was back.

Since life is short I gave up on it, but you just reminded me that maybe it's a good thing to try again and try to figure out where it goes wrong.

Now that I have a little bit more time, I'll try again and if I find out anything worth mentioning I'll let you know.

regards

Comment
Load more comments
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 18 March 2021 01:50 AM UTC
2 and a half hours later ...

I've tried and tried but I can't put my finger on it. It keeps failing at a certain point when I inherit a new object and step by step put the code in the events. I've got a window inherited from another, from another, from another, (pfc) and a tab inherited from a tab, inherited from a tab, the tab holds several tabpages (userobjects), inherited from tabpage userobject. That userobject holds references to the window it's place upon, etc. I guess it must be some kind of a cyclic reference thing.

Strangely enough, I have another tabpage with the same inheritance and bit less code, which does NOT present this problem of editing the source code.

It's driving me nuts, so time to get some sleep.

Sorry !

regards
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 18 March 2021 18:54 PM UTC
Hi Guys;

This issue has only happened to me a few times but I was always able to correct the problem by performing a full regeneration from the =>Object Browser<=. In the OB, you can expand the full inheritance tree of each object type and then perform a full regeneration from each top level ancestor. This process then *guarantees* that each proceeding ancestor is regenerated properly in sequence as the IDE goes down the inheritance hierarchy tree. In a normal Full Build from the IDE's System Tree, the objects are regenerated in PBL/Object order and *not* in their inheritance order. Thus, descendants can be regenerated before ancestors. Also, the OB regeneration will force code alignment. Food for thought.

The only other time that I got into your predicament and the OB regeneration failed to correct the situation - was when had corrupt source code in an object. The only way I suspected that this could happen was from a bad migration. Took me a while to locate the few lines of bad source code but once edited out, the problem went away permanently.

Regards ... Chris
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 18 March 2021 21:19 PM UTC
Thank you Chris, I'll give it a shot, but to be honest, I've been "full regenerating" this application for 5 years now on an almost daily base, so my hopes are pretty low. As long as I don't declare an instance variable in the inherited object, things go well. My guess is that something is wrong in the ancestor, but that one does let itself be edited in source code mode and never presents any problem. What calls my attention is that the create and destroy section in the exported code is right at the beginning. I'll post any further information if I can get any.

regards and thanks
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 18 March 2021 02:32 AM UTC
  2. PowerBuilder
  3. # 2

didn't this happen to you before?

https://community.appeon.com/index.php/qna/q-a/editsource-error

regards

Comment
Olan Knight
  1. Olan Knight
  2. Thursday, 18 March 2021 14:25 PM UTC
Yes, but the work-around - it certainly was not a "fix" - was time consuming and ugly. I never did figure out the actual cause of the error. I was hoping for a better resolution, and you may have found it!
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 18 March 2021 03:07 AM UTC
  2. PowerBuilder
  3. # 3

This is how I partially solved my problem.

I have 2 tabpages B1 and B2, both inherited from tabpage object (userobject) A.

If I edit the source code of B1, I can successfully save. The same thing for B2 fails.
I then noticed that the "B1" also started to fail, once I introduced an instance variable !!

What I did:

- declare the needed instance variables for B2 in the ancestor A and save A.
- (normal) Edit B2 and delete the instance variables and save.
- (source) Edit B2 and there was still an empty section "type variables - end variable". I deleted that section completely and was now able to save.

Not completely resolved, but at least it won't bug me anymore any time I want to Edit the source code.

HIH

Comment
Olan Knight
  1. Olan Knight
  2. Thursday, 18 March 2021 14:24 PM UTC
Thank.s Miguel! I'll try that today!
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 18 March 2021 14:31 PM UTC
Yw, you don't know how happy I am you asked this question. It's been a problem for years and it's just so annoying every time. Thanks to you I tried again, didn't get much sleep, but solved at least my problem,
  1. Helpful
There are no comments made yet.
Donald Clayton
Donald Clayton Accepted Answer Pending Moderation
  1. Tuesday, 14 May 2024 14:16 PM UTC
  2. PowerBuilder
  3. # 4

Hi Everyone,

Intertech recently came across this issue on a client project that would not build in PB 2022 R3 without blowing up the IDE after building the PBDs.  PBC builds do work but the application is too large to test thoroughly.  This particular error was shown when pulling the code from Git and checking the "Regenerate" checkbox in the Connect to Workspace dialog.

I'm curious to know exactly what "C0176: Badly ordered TYPE and VARIABLE declarations." means and what the compiler is looking for.  Can someone from Appeon engineering please weigh in on this?  

For example, does this mean that the entire TYPE and VARIABLE sections are out of order, or just the elements within?  Is it that the methods are out of order or not implemented in the right order?

Some clarity on what the compiler is actually checking for would be appreciated!

Thanks in advance,

Don

Comment
There are no comments made yet.
Steven Watkin
Steven Watkin Accepted Answer Pending Moderation
  1. Tuesday, 6 August 2024 18:01 PM UTC
  2. PowerBuilder
  3. # 5

Hello,

I was having this problem but I resolved it after much trial and error.

I have a tab on a window and I wanted each user object tabpage within the tab to refer to a windows function. I have several user object datawindows on each tabpage and I want them all to have the same data and properties so I use the window to keep them in synch.

To do that, each tab page declares and instance variable of that that window object. When I open the window, I set the instance variables for each tab page to "this", for example

tab_1.tabpage_1.i_parentwindow = this

tab_1.tabpage_2.i_parentwindow = this

......

 

The tabpages can refer to i_parentwindow to communicate with each other.

 

My problems started when I started doing this. I could not edit the source for any user object tab page and save it - and worse, the user object would get deleted no matter what I did, even if I declined to save it after getting the error. Sometimes I could and I thought I had it solved but the problem would always come back randomly.

 

Then I took out this instance variable and simply had the user objects refer to the window object rather than an instance variable. When I open the window, I open the Window object rather than declare an instance of it and open an instance. I can no longer open multiple instances of that window but I don't need to do that.

 

There is probably a more elegant way to accomplish what I want but this is now working well and without error.

 

 

 

Comment
John Fauss
  1. John Fauss
  2. Tuesday, 6 August 2024 19:08 PM UTC
An alternative that would permit you to open multiple instances of the window would be to add a function that dynamically traverses up the parent object hierarchy until it finds a window object to each tabpage user object, call it, say, of_GetParentWindow - Then call this function in the user object's Constructor event and save the reference to the parent window in the user object's instance variable. If you'd like to experiment and validate this approach, I can post an example of such a function for you... it's a relatively simple, small (~15 lines of PowerScript code if you do not count comment lines) function.

With this approach, you do not utilize the default global window variable (w_xxxxx), which allows multiple instances of the window to exist, and you avoid the issue using the "this" pronoun.
  1. Helpful 1
Steven Watkin
  1. Steven Watkin
  2. Sunday, 24 November 2024 15:48 PM UTC
Hello John,



The application has worked fine in production for the past few months where all the individual tab pages referenced the default global window variable (w_xxxxx) rather than opening an instance of this object and referencing the instance. I have never been completely OK with this approach, especially since this is the only window in the application that had to be referenced this way - because the tab pages all have datawindows that share the same data and properties - so I use the window to communicate between them.



So after a few months I looked at it again with a fresh mindset and the solution is amazingly simple. Each tab page declares a local window variable lw_xxxx of type w_xxxxx in the event script that needs to refer to these datawindows. Then in that script,



lw_xxxx = this.getparent().getparent()



Now I can refer to the datawindows in lw_xxxx as I need to AND I can open up multiple instances of that window if I want. No one will likely do that but they can if they want and this is now consistent with the rest of the application.



Thanks for giving me the idea of using getparent().



Steve
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.