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 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�
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.
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
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 0
ā 15
, system reserved.