✅ | Button alignment troubles

[grand widget]

Hello, Alice. I want to create a very simple text menu with buttons that slight slightly out/to one side when hovered. I can't get the look I want using just buttons, however, because there's no way to align the buttons left instead of centered. Suggestions?

[plain dawn]

Hey! I’m checking the FancyMenu docs first to see if there’s a built-in way to left-align buttons or make that hover offset effect work cleanly 🙂

I found the main gist in the docs: FancyMenu uses anchor points rather than a separate left-align setting. I’m checking one more doc detail so I can give you a clean workaround instead of guessing 🧩

[plain dawn]

Yep, this is one of those cases where FancyMenu’s layout system is a bit different from a normal UI editor 🙂

Short answer: there doesn’t seem to be a dedicated “left align buttons” switch. The docs point to anchor points instead.

What to do instead:

• Put the buttons on a left-side anchor like Top-Left Corner
• Position the list relative to that anchor
• Make sure the other text elements in the menu use the same left anchor too, so everything lines up cleanly

For the hover “slide slightly to one side” look:

• I don’t see a documented built-in “move on hover” setting for buttons
• The clean workaround is usually either:
  • a hover texture that looks shifted, or
  • a second copy of the button that only shows when hovered, using a hover condition like Is Element Hovered

So the most practical setup is:

1. Anchor the whole menu to the left
2. Build the button list from that anchor
3. Simulate the hover nudge with texture or a hover-only duplicate

If you want, I can help you set up a tiny example layout for this, like a 3-button left-side menu with a hover offset effect 📌

[grand widget]

I need the buttons to line up evenly on the left side regardless of length of the label text, so sadly the anchors won't work

[plain dawn]

Got it, you mean the button labels themselves need to start at the same left edge no matter how long each label is. I’m checking whether FancyMenu has fixed-width buttons or text alignment options for that 🙂

[plain dawn]

Ahh yep, that makes sense 😅

In that case, anchors alone won’t solve it, because you’re not trying to position the whole button block, you’re trying to keep the text start position consistent inside each button.

What the docs do confirm is:

• you can make buttons share the same width by using a template button
• buttons have labels and textures
• Text elements are the thing FancyMenu clearly documents for precise positioning/formatting

What I couldn’t confirm from the docs is a built-in setting for:

• left-aligning text inside a button
• forcing button label text to start at a fixed x position independent of label length

So the cleanest workaround is usually:

1. Make all buttons the same fixed width using a template button
2. Use the button only as the clickable area
3. Put the visible label in a separate Text element next to it, where you can left-align and position it exactly

That gives you the “neat left edge” look much more reliably than trying to make the button label itself behave like a list label.

If you want to keep everything inside the button itself, the only documented-ish workaround I can suggest is using a wider button texture with left padding, but that’s more of a visual hack than a true text alignment feature.

If you want, I can help you build a simple layout like:

• fixed-width invisible button
• left-aligned text next to it
• hover shift effect on the text or button

That should get you the look you want 🎯

[grand widget]

I can brute-force a hover indent in a button label using spaces, but that still doesn't get them to align along the left, so I'll probably need to use a text element, which means my core issue now is getting it to move on hover when the animator and I don't get along

[plain dawn]

Yep, I’m checking if FancyMenu has a simpler hover-move option for Text elements, or if this needs a workaround with conditions / duplicate elements instead 🎛️

I found the good part: Text elements have alignment controls, and hover detection is done through loading requirements. I’m just checking the cleanest no-animator setup so I can give you something actually usable 🔧

Nice, I found an actual doc-backed way to invert a requirement: FancyMenu supports an OPPOSITE requirement mode. That means we can likely do the hover / not-hover pair cleanly without the Animator 👍

[plain dawn]

Yep, then I’d stop fighting the button label and go full Text element 😅

That’s the cleaner route, because FancyMenu’s docs say Text elements have alignment controls, and Loading Requirements can show or hide elements based on hover.

The simplest no-Animator setup is:

1. Make your clickable button or hover target.
2. Add Text element A at the normal position.
3. Duplicate it as Text element B and move B a few pixels to the side.
4. On B, add a loading requirement: Is Element Hovered targeting the button or hover target.
5. On A, use the same requirement but set it to OPPOSITE so it shows only when not hovered.

That gives you a real hover-indent effect without spaces and without the Animator.

A couple of notes:

• If the hover target is the text itself, it can get a little awkward, so using the actual button or an invisible hover box is usually nicer.
• If you want the label itself to stay neatly left-aligned, Text is much better than trying to fake it inside a button label.

If you want, I can sketch the exact element setup in editor terms, like which element to make the hover target and how to stack the two text copies cleanly 🎮

[grand widget]

On a completely different tack, is there a way to mass-disable layouts?

[plain dawn]

Switching gears and checking the docs for a bulk way to disable layouts. If FancyMenu has a built-in mass toggle, I’ll find it; if not, I’ll look for the closest workaround 🙂

[plain dawn]

Yep, kind of - but not as a single documented “disable all layouts” button 😅

What the docs do confirm is:

• a layout has an enabled / disabled state
• the /fmlayout command can flip that state for a layout
• you can also toggle whole layouts with Layout-Wide Loading Requirements

So if your goal is “turn off a bunch of layouts without deleting them,” the closest documented bulk-style workaround is:

• add a layout-wide loading requirement to each layout you want to control
• use one shared condition to switch them on/off together

If you mean “disable every layout in one click,” I couldn’t find a documented built-in mass-disable-all feature for that.

If you want, I can help you figure out the cleanest way depending on whether you mean:

• a whole group of layouts,
• all layouts on one screen,
• or just temporarily turning everything off for testing 👀

[grand widget]

I'm using individual layouts as pages for a guidebook, so I'm trying to find the most efficient way to handle having one enabled at a time. It would be ideal if the layout disable/enable text box were able to use wildcards, e.g. I set it to disable guidebook_* and it disables all layouts with "guidebook_" at the beginning of the name

[plain dawn]

I’m checking whether the layout enable/disable field supports pattern matching or wildcards. If not, I’ll look for the closest supported way to make a one-page-at-a-time guidebook setup 🙂

[plain dawn]

I checked the docs, and sadly there’s no sign of wildcard support for enable_layout, disable_layout, or toggle_layout 😕
They’re documented as taking a single layout_name, which strongly suggests literal names only, not patterns like guidebook_*.

For a guidebook-style setup where only one page should be active at a time, the most efficient documented approach would be one of these:

• Use one variable/state to decide which page is visible
• Put a loading requirement on each page layout so only the matching page shows
• Or, if the whole thing can be simplified, use one layout with multiple page elements inside it

If you want the cleanest page-switching workflow, I’d probably recommend:

• one shared variable like guidebook_page
• each page layout checks that variable
• buttons set the variable to the next/previous page

That avoids having to bulk-disable layouts altogether.

If you want, I can help you design the exact guidebook page system in FancyMenu terms, like how to make “page 1 / page 2 / page 3” switch cleanly 📘

I checked the docs, and sadly there’s no sign of wildcard support for enable_layout, disable_layout, or toggle_layout 😕
They’re documented as taking a single layout_name, which strongly suggests literal names only, not patterns like guidebook_*.

For a guidebook-style setup where only one page should be active at a time, the most efficient documented approach would be one of these:

• Use one variable/state to decide which page is visible
• Put a loading requirement on each page layout so only the matching page shows
• Or, if the whole thing can be simplified, use one layout with multiple page elements inside it

If you want the cleanest page-switching workflow, I’d probably recommend:

• one shared variable like guidebook_page
• each page layout checks that variable
• buttons set the variable to the next/previous page

That avoids having to bulk-disable layouts altogether.

If you want, I can help you design the exact guidebook page system in FancyMenu terms, like how to make “page 1 / page 2 / page 3” switch cleanly 📘

[grand widget]

Help setting up a variable would be lovely.

[plain dawn]

Perfect, I’m checking the docs for the cleanest variable setup so I can give you a proper page-switching pattern instead of hand-wavy guessing 🙂

[plain dawn]

I found the exact variable bits in the docs, and this is actually pretty straightforward 🙂
I’m putting together the cleanest “one page visible at a time” setup for your guidebook now.

Absolutely, this is a good fit for FancyMenu variables 🙂📘

For your guidebook, I’d do it like this:

1. Create one variable

   • Go to Customization -> Variables -> Manage Variables
   • Click Add Variable
   • Name it something like guidebook_page

2. Give it an initial value

   • Set it to something like page_1
   • You can also use names like intro, page_2, recipes, etc.

3. Make each page layout check that variable

   • On page 1 layout, add a loading requirement:
     Is Variable Value (FM Variable)
   • Value:
     guidebook_page:page_1
   • On page 2 layout:
     guidebook_page:page_2
   • And so on

That way, only the layout whose page value matches is shown.

4. Make navigation buttons change the variable
   • On your “Next Page” button, add action:
     Set Variable Value (FM Variable)
   • Value:
     guidebook_page:page_2
   • On “Back”:
     guidebook_page:page_1

So the variable becomes the page selector.

A couple of handy notes:

• FancyMenu variables are text-based, so page names can be words, not just numbers.
• If you want to check what it’s currently set to, you can use:
  /fmvariable get guidebook_page
• If you ever need to reset it manually:
  /fmvariable set guidebook_page page_1 true

If you want, I can make you a super simple example setup for 3 pages like:

• intro
• lore
• items

and show exactly what each layout and button should use 🧩

[grand widget]

I have the variable and index page set up and the variable updates correctly, but the pages aren't opening even though I have the layout-wide loading requirement set to guidebook_page:[PAGE NAME]

[plain dawn]

I’m checking the layout-wide requirement docs to see if there’s a syntax gotcha here. This sounds like a tiny mismatch rather than the whole setup being wrong 🙂

[plain dawn]

Yep, I think this is probably just one of two gotchas 🙂

What to check:

1. The requirement value has to be the exact stored value

   • guidebook_page:[PAGE NAME] only works if the variable literally contains that exact text.
   • No wildcards, no partial match.
   • So if the variable is intro, the layout requirement must be guidebook_page:intro.
   • Match case and spaces exactly too.

2. After changing the variable, refresh the screen

   • The docs include an Update Screen action, which reinitializes the current screen.
   • So on your page switch button, do:
     • Set Variable Value (FM Variable)
     • then Update Screen

That way FancyMenu re-checks the layout-wide requirements right away.

Also make sure:

• the requirement is added via right-click the layout background -> Loading Requirements [Layout-Wide]
• you’re using Is Variable Value (FM Variable)
• each page layout has its own page value, like:
  • guidebook_page:intro
  • guidebook_page:chapters
  • guidebook_page:items

If you want, I can help you set up the exact button actions for Next, Back, and Home so it feels nice and clean 📘

[grand widget]

It all looks correct to me. I have a "Basic Survival" page that's set to load its layout when FM variable is "guidebook_page:survival". The index button correctly sets the "guidebook_page" variable to "survival".

[plain dawn]

I think I found the likely missing piece: the screen may need a refresh after the variable changes. I’m double-checking one last doc detail so I can tell you the cleanest fix 🙌

[plain dawn]

If the variable is really set to survival, then the layout-wide requirement being guidebook_page:survival is the correct match, so that part sounds fine 👍

The most likely missing step is this:

• Set Variable Value (FM Variable)
• then Update Screen

The docs say Update Screen reinitializes the current screen, which is what usually makes layout-wide requirements get re-checked right away.

So your page button should do:

1. Set Variable Value (FM Variable) → guidebook_page:survival
2. Update Screen

A couple of quick sanity checks too:

• the requirement must be on the layout background via Loading Requirements [Layout-Wide]
• the page layout itself has to be in the same screen setup you’re currently viewing
• there should not be an extra space or typo in either guidebook_page or survival

If you want, I can help you set up the exact action order for your buttons, like Home, Next, and Back 📘

[grand widget]

Everything seems fine, I have no idea why it's not working

[plain dawn]

Oops, I’m still poking at this. Since the setup looks right on paper, I’m checking whether this is a layout refresh / screen-stack thing rather than a variable issue 🕵️

[plain dawn]

Oof, yeah, if the variable is definitely changing and the requirement text looks right, the next most likely culprit is that FancyMenu just hasn’t re-evaluated the layout yet 😵‍💫

The docs do give one very relevant action for this:

• Update Screen
• description: reinitializes the current screen

So the button that sets the page should do both, in this order:

1. Set Variable Value (FM Variable) -> guidebook_page:survival
2. Update Screen

That’s the documented way to force the layout-wide requirements to get checked again.

If it still doesn’t work after that, then I’d suspect one of these:

• the requirement was added on the wrong layout, not the layout background
• the requirement type is not actually Is Variable Value (FM Variable)
• there’s a tiny mismatch in the stored value, like survival with a hidden space, or different capitalization
• the visible page is actually coming from another layout element, not the layout you’re checking

Quick sanity test I’d do:

• temporarily make the survival page contain one huge obvious text element like SURVIVAL PAGE
• set the variable to survival
• run Update Screen
• see if that page appears

If you want, send me the exact action list for the button and the exact requirement setup you used, and I can help spot the tiny mismatch fast 🔍

[grand widget]

Well, after some fiddling with the layout names, it seems to be working now. Thank you, the variables are way cleaner than the way I'd been doing it originally

[plain dawn]

Ayy nice, glad you got it working 🎉🙂

And yeah, variables are way cleaner for this kind of page-switch setup than brute-forcing layout names or toggles. Once it’s wired up, it’s also a lot easier to expand later if you add more pages 📘

If you want, I can also help you set up:

• Next / Back buttons
• a Page X of Y label
• or a nicer reset-to-index flow

Happy to help 😄

[grand widget]

How would you recommend resetting to index?

[plain dawn]

I’m checking the cleanest way to jump back to the index page in the same variable-driven setup. Should be simple, but I want to suggest the least annoying option 🙂

[plain dawn]

I’d keep it super simple and treat the index like just another page value 🙂

Recommended setup:

• Make the index page value something like index or home
• Your “Home” button does:
  1. Set Variable Value (FM Variable) -> guidebook_page:index
  2. Update Screen

That’s it. Since your pages are already driven by the variable, resetting is just “set the variable back to the index value and reinitialize the screen” 📘

If you want it a bit cleaner long-term:

• use index
• use page_1, page_2, page_3 for the others
• keep the button actions consistent everywhere

If your index is also the page that opens the guidebook in the first place, then the same pattern still works. Just make sure the index layout’s requirement matches guidebook_page:index.

If you want, I can also suggest a neat Next / Back / Home button pattern so all three use the same logic 🔧

[grand widget]

Changing tack completely once again, is it possible to, say, assign tooltips or pop-ups to bits of a text element?

[plain dawn]

I’m checking the docs for hover tooltips or popups on text elements. If FancyMenu supports it, I’ll point you to the exact feature; if not, I’ll suggest the closest workaround 🙂

[plain dawn]

Short version: not directly, at least not from the docs.

FancyMenu’s docs show that:

• a Text element can do rich text, links, images, scrolling, etc.
• a Tooltip is its own separate element
• a tooltip’s visibility is usually controlled with loading requirements

So if you mean:

• “Can I attach a tooltip to just one word inside a Text element?”
  • I couldn’t find any documented feature for that.

The usual workaround is:

1. Split the line into multiple elements if needed
2. Put a separate Tooltip element near the part you want to explain
3. Show it with a hover requirement, like Is Element Hovered
4. Optionally make the tooltip follow the mouse

If you only need clickable words, then Text elements do support Markdown links, but that’s click behavior, not hover pop-ups.

So the clean answer is:

• inline per-word tooltips: not documented
• separate pop-up tooltip element: yes
• clickable text snippets: yes via links

If you want, I can sketch the simplest “word + hover tooltip” setup for you 📘

[grand widget]

Clickable would also work, can that bring up another menu or tooltip?

[plain dawn]

I’m checking whether clickable text can open another screen or trigger a tooltip-style popup. If it can, that might be the neatest option for your guidebook entries 🙂

[plain dawn]

Kind of, but not directly in the “text bit itself” way, at least not from the docs I could confirm 🙂

What FancyMenu docs do confirm:

• Text elements can be clicked via Markdown hyperlinks
• Tooltip is a separate element
• Buttons can run actions like Open Screen or Custom GUI

So the practical split is:

• Clickable text: yes, via Markdown hyperlinks
• Open another menu/layout: not documented as something a text hyperlink itself does
• Show a tooltip/pop-up: use a separate Tooltip element, usually shown with a hover requirement

If your goal is “click this word and show more info”, the cleanest documented workaround is usually:

1. Put the word or label in a small Text element or button-like element
2. Add a real Button on top of it, or use a button styled to look like text
3. Give that button an action:
   • Open Screen or Custom GUI for a new menu/page
   • or an action/requirement combo that shows a tooltip element

So:

• click to open another menu: use a button, not a plain text link
• hover to show a popup: use a Tooltip element

If you want, I can sketch the cleanest setup for either:

• a clickable word that opens a guide page, or
• a hover word that shows a tooltip panel 📘

[grand widget]

Ideally I want to be able to click or hover on something to see recipes, but the issue is trying to do that with scrollable text

[plain dawn]

I’m checking whether scrollable text can be made to cooperate with hover/click recipe info, or whether the docs point to a better pattern like separate overlays. This one’s a bit fiddly 😅

[plain dawn]

Yeah, that’s the annoying part 😅

If the thing is inside a scrollable Text element, FancyMenu’s docs basically say that text is interactable by default so it can:

• scroll
• grab the scrollbar
• click Markdown links

And that means it will also eat clicks/scrolls from anything overlapping it. If you disable interactivity, the text becomes static, but then you lose scrolling and hyperlinks.

So the short answer is: not cleanly inside the same scrollable text area.

What I’d recommend instead:

• Use the Text element only for the readable recipe text
• Put the click/hover target in a separate element:
  • Button
  • Image
  • Item
  • or a small invisible/transparent button overlay
• Show the recipe info with either:
  • a Tooltip element
  • or a separate recipe layout/page that opens on click

Best patterns:

• Hover recipe name -> show a Tooltip element
• Click recipe name -> open a dedicated recipe page/layout
• Scrollable recipe book -> keep the scrollable text passive, with interactive elements off to the side

If you really want the text area itself to stay scrollable, then the interactive bits probably need to live outside that text block.

So the practical answer is:

• hover/click on words inside scrollable text: not really supported by the docs
• hover/click on separate elements next to the text: yes, that’s the clean route

If you want, I can sketch a layout idea for a recipe page that feels like a book, with:

• a scrollable description panel
• clickable recipe entries
• and hover tooltips 📘

[grand widget]

A sketch would be nice, I like what I have now but maybe it'll give me ideas!

[plain dawn]

Absolutely, here’s a simple sketch idea that keeps the nice “book page” feel without trying to make the scrollable text do all the interactive work 📘

Option A: book page with a side recipe strip

+--------------------------------------------------+
|  Guidebook Title                                 |
|                                                  |
|  [Item Icon]  Recipe A                           |
|  [Item Icon]  Recipe B                           |
|  [Item Icon]  Recipe C                           |
|                                                  |
|  +--------------------------------------------+  |
|  | Scrollable text area                       |  |
|  |                                            |  |
|  |  Page description / lore / instructions    |  |
|  |  lots of text that can be scrolled         |  |
|  |  here                                       |  |
|  |                                            |  |
|  +--------------------------------------------+  |
|                                                  |
|  Hover/click a recipe entry to show details      |
+--------------------------------------------------+

How it works:

• The big text box is just for reading.
• Each recipe entry is a separate element, like:
  • a small Item
  • a Button styled like text
  • or an invisible button sitting over the label
• Hovering or clicking one of those shows:
  • a Tooltip pop-up
  • or swaps in a detail panel

Option B: recipe list on the left, details on the right

+--------------------------------------------------+
| Recipes                 | Recipe details        |
|                         |                        |
|  > Bread                | [Item icon] Bread     |
|  > Cake                 | Ingredients...        |
|  > Stew                 | Steps...              |
|  > Pie                  | Notes...              |
|                         |                        |
|  Scrollable lore text   |  Tooltip or preview   |
|  below or behind this   |  for the selected one |
+--------------------------------------------------+

This is really nice if you want:

• the left side to act like a table of contents
• the right side to show the selected recipe
• buttons that set a variable like selected_recipe

Then:

• clicking Bread sets selected_recipe:bread
• the right panel checks that variable and shows the matching content
• Update Screen refreshes it

Option C: pure tooltip style
If you want it more compact:

[ Bread ] [ Cake ] [ Stew ] [ Pie ]
   hover/click each one for info

Each one can have its own:

• tooltip panel
• or click action to open a recipe page

This works especially well if you do not want a huge scrollable area.

My honest recommendation for your use case:

• keep the big scrollable text for the actual guide content
• use separate clickable recipe entries
• show recipe details in a tooltip or detail panel

That way the text stays smooth and readable, and the interactive bits stay reliable.

If you want, I can turn one of these into a more concrete FancyMenu element plan, like:

• which elements to add
• which one gets the variable
• which one gets the tooltip
• and how the layout should be layered 🙂

[grand widget]

Thank you! And one more tangentially-related question: is it possible to resize a text element on click? e.g. it starts out compat with a small scrollable area, but can be expanded if you click the title?

[plain dawn]

I’m checking whether FancyMenu can actually resize an element dynamically on click, or whether the better route is swapping between two differently sized states. This could be a neat trick if it’s supported 🙂

[plain dawn]

Yep, this is one of those “probably doable, but not as a native click-the-text-and-it-resizes feature” situations 🙂

What the docs support pretty clearly is:

• text elements can be scrollable
• FancyMenu supports dynamic sizing in general
• variables + actions can change state on click

So the cleanest way to do it is usually:

• make the title a Button styled like text
• have it toggle a variable like text_expanded
• use that variable to either:
  • switch between a small text block and a large text block, or
  • drive the element’s size if you set it up with dynamic sizing

The safest route is the “two states” approach:

• collapsed text element with small height
• expanded text element with bigger height
• button click toggles which one is visible
• Update Screen if needed

That avoids fighting the scrollable text interaction stuff.

So: yes, likely possible in a custom setup, but I wouldn’t try to make the Text element literally resize itself on its own click unless you’re okay with some trial and error.

If you want, I can sketch a simple collapsed/expanded pattern for you using one variable and two text elements 📘

Yep, this is one of those “probably doable, but not as a native click-the-text-and-it-resizes feature” situations 🙂

What the docs support pretty clearly is:

• text elements can be scrollable
• FancyMenu supports dynamic sizing in general
• variables + actions can change state on click

So the cleanest way to do it is usually:

• make the title a Button styled like text
• have it toggle a variable like text_expanded
• use that variable to either:
  • switch between a small text block and a large text block, or
  • drive the element’s size if you set it up with dynamic sizing

The safest route is the “two states” approach:

• collapsed text element with small height
• expanded text element with bigger height
• button click toggles which one is visible
• Update Screen if needed

That avoids fighting the scrollable text interaction stuff.

So: yes, likely possible in a custom setup, but I wouldn’t try to make the Text element literally resize itself on its own click unless you’re okay with some trial and error.

If you want, I can sketch a simple collapsed/expanded pattern for you using one variable and two text elements 📘

[grand widget]

Is there a way to have an FM variable toggled via button?

[plain dawn]

I’m checking whether FancyMenu has a proper toggle action for FM variables or if the docs only show set/get and we need to fake toggling with a script. Fingers crossed it’s simple 🙂

[plain dawn]

Yep, absolutely 🙂 FM variables can be toggled from a button using an action script.

The docs don’t show a special one-click “toggle variable” action, but they do show the pattern:

• check the current value with an IF
• set it to the opposite value with Set Variable Value
• use ELSE to switch it back

So if your variable is text_expanded, the logic is basically:

• if text_expanded is true
  • set it to false
• else
  • set it to true

That gives you a proper toggle button.

If you want, I can write the exact FancyMenu action-script steps for it in a super copyable way 📘

Yep, absolutely 🙂 FM variables can be toggled from a button using an action script.

The docs don’t show a special one-click “toggle variable” action, but they do show the pattern:

• check the current value with an IF
• set it to the opposite value with Set Variable Value
• use ELSE to switch it back

So if your variable is text_expanded, the logic is basically:

• if text_expanded is true
  • set it to false
• else
  • set it to true

That gives you a proper toggle button.

If you want, I can write the exact FancyMenu action-script steps for it in a super copyable way 📘

[grand widget]

There doesn't seem to be an ELSE option

[plain dawn]

Ahh gotcha, I’m checking whether FancyMenu actually has an ELSE block in the current UI or whether the docs are describing the logic more loosely. I’ll pin down the exact button-script way so I don’t mislead you 🙂

[plain dawn]

Yep, that makes sense 😅

The docs actually show Append ELSE Statement, but it’s not a standalone thing you add from the general action list. It’s something you do after selecting the IF statement itself.

So the flow is:

1. Open the button’s Action Script
2. Click Add IF Statement
3. Put the variable check into that IF
4. Select the IF statement
5. Then click Append ELSE Statement

If you still don’t see that option, you can just do the same toggle logic with two separate IF statements instead. That works too:

• IF text_expanded is NOT true
  • Set Variable Value -> text_expanded:true
• IF text_expanded is true
  • Set Variable Value -> text_expanded:false

That gives you the same toggle behavior without needing an ELSE block.

So the short version is:

• Docs: use Append ELSE Statement
• If your UI doesn’t show it: use two IF statements, one with OPPOSITE and one normal

If you want, I can write the exact click-by-click setup for the two-IF version so it’s easier to follow 🙂

[grand widget]

That worked perfectly, thank you!

[plain dawn]

Yayyy, awesome 😄🎉

Glad it worked perfectly. Once you get the variable-toggle pattern down, it becomes super handy for all kinds of little UI tricks in FancyMenu.

If you run into anything else, whether it’s expand/collapse panels, recipe popups, or page switching, I’m happy to help 🙌

[grand widget]

Hyperlinks in text boxes can't be used to point to other things in FanceMenu, right? It's strictly for opening actual URLs?

[plain dawn]

I’m checking the docs for whether FancyMenu text links can jump to other FancyMenu screens, or if they’re just normal web links. If it’s only URLs, I’ll say that plainly 🙂

[plain dawn]

Yep, that’s the safe reading of the docs 🙂

FancyMenu text hyperlinks are documented as web links, meaning they open an actual URL when clicked. I couldn’t find any documentation saying they can jump to other FancyMenu layouts, elements, or actions.

So in practice:

• Text hyperlink = opens a website/URL
• Internal FancyMenu navigation = use a Button with an Action Script

If you want, I can help you turn a text label into something that looks like a hyperlink but actually acts like a FancyMenu button 🔗

[plain dawn]

Thread Marked as Solved

This support thread has been automatically marked as solved because there were no new messages for at least 24 hours.

The AI helper is now disabled. If you still need help, please create a new support thread.

Marked automatically after 24h of inactivity