Shampoo’s still in development, albeit passively. I’m sitting on a half-complete update that adds a bunch of optimizations (like significantly faster text parsing) and extended non-desktop device support. I don’t have an ETA but questions like this motivate me to continue working on it :)

Hey! This should be an easy fix. It looks like you need to set the project directory in the create event of object obj_shampoo. Check out the Setup section of the documentation: https://github.com/zbanack/shampoo#installation-and-setup

If you get an error when running Shampoo in GMS v2.3.2.556, this one-liner should solve the problem until I push an official update.

First, go to function sh_tags_define in script ShampooAttrs.

Next, find the line (should be line 624) reading

var accepts_map = ds_map_create();

Underneath, add the following:

if (!is_array(accepts)) accepts = [];

Here’s a picture of what it should look like.

Currently, the only way to make a canvas background transparent is this hacky workaround of assigning an invisible sprite to it. Hah :x Hopefully that’ll be okay for the time being

Oops, forgot to respond but yes! Your solution looks good and I can do precisely the sh_singleton syntax so the next update should go seamless on your end. And there are ways to get variables to leave the scope of the function they’re called in.

For example, suppose I have a global function:

function set_name() {
    name = "hi";
}

Any object that calls that function would have a variable name set to "hi".

Hey, I’m glad you’re enjoying the framework! I don’t have an ETA for the scrollviews update at the moment, but I’m also excited for them.

I had mouse-cursor manipulation mostly implemented prior to the framework’s release, but I scrapped it because I was getting inconsistent results on Windows and Mac. Maybe now I can look again with a fresh pair of eyes.

The knob-slider precision thing was intentional, but I’m not opposed to either reverting the decision or adding an optional attribute (like, precise) to enable/disable precision.

And block-style input started as a way to lessen the number of edge cases the framework would need to account for (element alignment, input handling, overflow to the next row, etc.). But I think enough code has been refactored from v0.9.0 to v0.9.2+ that would make non-block-style inputs practical. I’ll add investigating this to my TODO :)

Hey Carson, I’ll add built-in GM function support to callbacks to my TODO list! I’m glad you were able to figure it out. I’ll also convey more clearly in the docs that a valid callback function is necessary for buttons/links in order for them to be ‘hoverable’ (it’s a failsafe to prevent crashes during live-coding by calling a non-existing function).

Fixed in v0.9.21, thanks for your patience!

The slider now accepts value=real, value={$var}, etc.

If you’re curious. The issue was that the slider tag accepted value-real instead of the value attribute. The value-real variant is an under-the-hood naming convention to prevent look up table conflicts. Now, value is auto-changed to value-real when detected in a slider tag.

Fortunately based on your glitched screenshot, I may have an idea of approximately where in Shampoo’s code the conflict arose.

Though it may come down to a struct-level variable of mine being named after a function of Tweenline. e.g. I have a variable called counter, and Tweenline has a function called counter.

If that’s the case, I may have to get more descriptive with my variable names because more conflicts are inevitable as Shampoo makes its way into more existing projects.

I’ll download Tweenline and see if I notice any naming conflicts. Tween engines are popular so I’d hate for Shampoo to not be compatible with one of the big ones.

All resources, functions, globalvars, enums, etc. have either a shampoo_, SH_, or Sh prefix to prevent naming conflicts. But it’s likely one of my (non-prefixed) variable names is conflicting with something in Tweenline’s.

Happy to see you figured out the issue though!

I’ll have this fixed midday Friday EST most likely! Thanks for uncovering this, I should have caught this prior to release…

Hey sodabeam! Thanks again for your patience. Just now, I’ve successfully imported Shampoo into several existing projects of mine (one even converted from GMS 1.4 -> 2.3; different game settings; different directories, etc.) but can’t seem to recreate the issue. I’ll be investigating further. But until then, if you’d like a refund for your purchase, I have no problems with that :)

Thanks for the info, that’s real odd… I’ll get to the bottom of this ASAP (I’m with some family for the holidays). I appreciate your patience

Hi, sorry to hear about the problems – haven’t heard of this issue before. A couple questions and hopefully we can get this fixed! First, can you verify the Shampoo demo works as intended on its own (outside of your existing project)?

Second, what OS and GM Runtime version are you using?

Thanks!

Thanks! Yeah, that’s basically what I have in mind with scrollbars: horizontal, vertical, and panning with cursor/finger. In other words, scrollviews will (ideally) be rectangles with content inside that you can move around

Hey Mickey! Getting Shampoo working smoothly with HTML5 is a big priority for me. Here’s an HTML5 demo of where it stands at the moment. The text isn’t sharp and the performance is pretty lousy when new menus are being generated https://www.banack.me/shampoo_html5_demo/.

While I don’t have the Android export module or an Android device, I do have plans on mobile support. Specifically, things like bringing up the keyboard when a text field is in focus.