Eeprom collision

Can you try it now @pharap? Are you seeing the large or small version of the popup? I have also added a scroll bar (up / down) as it was very tall.

I already tried it, hence the like on the post above.

If I look at it with a maximised window I get a horizontal scrollbar as well, and the names are a tad squashed.

(Not that that matters to me, since I probably won’t be using a maximised view anyway.)

Ah … I thought you had done that before I added the scroll bar. I had only added it moments before you posted.

Its an interesting problem with jQuery dialogues or - more likely - my understanding of them and how best to handle sizing.

I check the window’s width as I initialize the dialogues (onDocReady) but when I render the content of the dialogue (on clicking of the button), I check the window size again to see whether to use the narrow or wide rulers. If you had refreshed the page (or come into it full sized) then the second version would have worked - its a result of you resizing the window after the initial onDocReady(). Not sure best way to fix that …

I could always store the initial width away somewhere and use it when rendering the content but that seems a little backwards. Would be better to re-initialise the dialogue on clicking the button.

You could store the window dimensions and reinitialise only if they’ve changed?
It depends how expensive it is to build the dialogue I guess.

As I’ve never used jQuery, I have no idea how it goes about building/handling these things.

I don’t do web dev very often, but when I do I prefer to be very minimalist and stick to the built-in tools, so I’d typically use CSS tricks like media queries, flexboxes, using percentages for width and height or margin: 0 auto; to respond to changing window sizes.

Perhaps there’s a way you can use those to make the dialogue automatically resize itself as the window resizes?

I am using a dialogue for the EEPROM analysis which I suspect is probably not supposed to resize dynamically based on the window size at the time of rendering. I suspect the intent of the dialogue is for simple messages and minimal data capture, not a large info display like I am doing.

Neither do I … and I now remember why. It sux.

I have done nothing with ‘media queries’ but a little with flexboxes. I understand how they change relative to the window size but these dialogues are different - they pop up (like a dialogue!) over the top of other content.

I am not overly concerned about resizing dynamically once the dialogue is open - that’s the user’s problem not mine :slight_smile: However, I could spend a little time to handle screen resizes prior to opening the dialogue.

Or not … I am happy for a web person to get involved!

Hi @filmote
I now just get a pop window thats says true and always reopens when I try to close it…
Is this just for me…? :laughing:

I had a quick peek via F12 and it seems you (or perhaps jQuery?) aren’t using the acutal dialog tag, it’s using a regular div and doing absolute positioning with a high z index.

For comparison did a quick test with w3schools’s dialog tag demo by adding style="width: 50%" and style="width: 80%" and it resizes.

I don’t know if the same rules would apply to what you’re doing though. I’m presuming ui-dialog is a jQuery thing?

Yep. Too many weird rules, edge cases and surprising behaviours.

Flexbox changes relative to the size of the outer content, not just relative to the size of the window.

Here’s a quick demo I knocked together:

Open it in a browser and then slowly make the page as narrow as you can and watch what happens.

It’s not the behaviour you want, but the point is to show how it’s possible to make content automatically move around in reaction to a changing viewport via CSS.

Notice I’m using a dialog, which also appears over top of other content. Being rendered above other content shouldn’t restrict an element’s ability to change in size relative to the window size.

Though I notice your dialogue box is draggable, which would be an awkward thing to handle if the size of the dialogue changes in response to the window size.

Perhaps there’s some way to make a dragable corner that would resize the dialogue as a window would in a normal GUI toolkit, though that would be beyond what I know.

(Even if none of this helps you now, perhaps it’ll come in handy in the future, if you’re ever subjected to the horrors of webdev again.)

Refresh, Ctrl-F5 ?

Nope. Still just ‘true’…

It’s a caching issue.

Another reason I dislike web development.

That’s correct. I am using the jQuery dialog which is as you say a stylised div. I am familiar with the jQuery one but assume the two operate similarly - both are simply a container for content.

Not that I really needs it to be in my example.

And now?

I refreshed the pages on the site … just in case.

Once I get the crowdfunding up for the mini I want to highlight this from the main page. Used this to built a cart for it, went well.

1 Like

And now? 

Howdy folks! I am really late to the game (no pun intended) and was hoping there was a “cheat sheet” of sorts to guide my efforts in updating Evade :). There’s clearly been a ton of development and it’s a bit hard for me to follow the various threaded conversations :slight_smile:

1 Like

TL;DR –
@Pharap is working on a nice update for the Arduboy2 library for EEPROM handling. If you use that, I’d wait to get the official update. It should standardise how EEPROM is used and includes a hash function for detecting if the game save was corrupted (from a collision). There’s a nice (draft) guide here.
You can see a map of EEPROM usage (more or less dense addresses), using @filmote’s cart-builder website. Changing addresses may reduce the chance of collision, as will using less bytes if possible. Avoid writing to 015, system reserved.

1 Like