Oracle Forms vs Power Apps

This actually makes the “doh!” funnier. 😄

I was solving it at the control-coordinate level when my old Oracle*Forms brain already knew the better abstraction:

record → form → fields → validation → save

Power Apps just buried the familiar idea under enough modern UI gravel that I spent the day rediscovering 1990s wisdom.

Screen
└── Vertical container
├── Quickpick
│ └── Centre dropdown
│
├── Single record
│ └── Centre/Info Form
│
├── Multiple records
│ └── Contacts Gallery
│
└── Multiple records
└── Regions Gallery

The concepts map surprisingly well:

Oracle block/form record → Power Apps Form
Item/data source → current record
fields/items → Data Cards
commit → SubmitForm()
query/detail repetition → Gallery
master/detail → dropdown-selected Centre + related Contacts

I should be able to include words like canvas for completion

Canvas App
└── Screen
    └── Canvas
        └── Vertical container
            ├── Block / Control
            │   └── Quickpick
            │       └── Centre dropdown
            │
            ├── Block / Control
            │   └── Single record
            │       └── Centre/Info Form
            │
            ├── Block / Control
            │   └── Multiple records
            │       └── Contacts Gallery
            │
            └── Block / Control
                └── Multiple records
                    └── Regions Gallery

Our old “blocks” are basically the controls you place on the canvas: Dropdown, Form, Gallery, Button, Label, Container, etc.

So the hierarchy is:

Canvas App → Screen → Canvas → Container → Controls (“blocks”)

App → Screen → Containers → Controls → Data

Terms

Canvas App = whole app
Screen = one page inside it
Container = structural layout region
Control = form, gallery, dropdown, label, button, etc.
Data source = SharePoint/Microsoft List connection
Form = one record
Gallery = multiple records

And the “three levels of separation” you saw were very likely nested containers.

For example:

Canvas App
└── Screen
    └── Main Vertical Container
        ├── Header Container
        │
        ├── Main / Body Container
        │   ├── Centre dropdown
        │   ├── Centre/Info Form
        │   └── Contacts Gallery
        │
        └── Footer Container

Microsoft’s responsive layouts are built from exactly this sort of nesting. A vertical parent can contain separate header, body and footer containers, and child containers can themselves be horizontal or vertical.

The bit called “sub main” was probably another child container inside the main/body container:

Main / Body Container
├── Centre/Info Container
└── Contacts Container

And if the Contacts controls suddenly appeared vertically, that strongly suggests the container we added was a Vertical container. Vertical containers automatically stack their children top-to-bottom. Horizontal containers place their children side-by-side.

So your snapshot may actually have looked closer to this:

Canvas App
└── Screen
    └── Vertical Container
        ├── Header
        │
        ├── Main
        │   ├── Centre/  Info
        │   └── Contacts
        │
        └── Footer

with Main, Centre/Info, and Contacts themselves potentially being containers.

One important distinction: Microsoft also has Groups, but those are mostly an editing convenience. A Group does not control layout. A Container does.

So for your mental snapshot, I’d use:

App → Screen → Containers → Controls → Data

That is probably the missing vocabulary layer from today.

O365

Terms

Hmmmm