Touble with having links in both status window and buffer window (Bisquixe?)

I’ve tagged this with “bisquixe”, but this problem happens in every interpreter I’ve tried. It isn’t an html issue. (edit)I’m not completely certain that it is a Bisquixe-specific problem.(edit 2)Or maybe it is! See post #2)

If I add hyperlinks to both status window and buffer window, they appear to be in contention. If I click the link in the status window, links in the buffer window stop working. They are highlighted as clickable, but clicking does nothing. The opposite is true, as well.

The problem happens with Bisquixe’s built-in hyperlink feature, but it also happens while using the alternate inline method provided here.

Here is a minimal example. Sorry so long, but a lot of definitions are needed for the inline links. This code includes both Bisquixe and inline hyperlinks for comparison’s sake.

Code
lab is a room.

include simple multimedia effects for v10 by mathbrush.
include formatting capture by daniel stelzer.

before reading a command:
	say frob;
	say line break;
	say "[link]jump[with]inline[end link]";
	say line break;
	
to say frob:
	hyperlink "bisquixe" as "jump";
	
when play begins:
	now left hand status line is "[frob]";
	now right hand status line is "[link]jump[with]inline[end link]";


[--------------------------------------]

	
[begin code by Daniel Stelzer]
	

The inline hyperlinked command is a text variable.

To begin link:
	if expanding text for comparison purposes, stop;
	now the inline hyperlinked command is "";
	start capturing text.

To say link command -- beginning say_link -- running on:
	begin link.

To say link -- beginning say_link -- running on:
	begin link.

To say l -- beginning say_link -- running on:
	begin link.

To continue link:
	if expanding text for comparison purposes, stop;
	stop capturing text;
	now the inline hyperlinked command is the substituted form of "[captured text without formatting]";
	start capturing text.

To say with text -- continuing say_link -- running on:
	continue link.

To say with -- continuing say_link -- running on:
	continue link.

To say = -- continuing say_link -- running on:
	continue link.

To end link:
	if expanding text for comparison purposes, stop;
	stop capturing text;
	if the inline hyperlinked command is empty:
		now the inline hyperlinked command is the substituted form of "[captured text without formatting]";
	hyperlink "[captured text]" as the inline hyperlinked command.

To say end link -- ending say_link -- running on:
	end link.

To say /link -- ending say_link -- running on:
	end link.

To say /l -- ending say_link -- running on:
	end link.```

I am wondering if this incompatibiliy can be resolved. Is it an issue with links generally? Or is it a problem with my code (very likely)?

The inline method just calls the Bisquixe method, so it makes sense that a problem with one affects the other as well. I have a suspicion, but let me make some experiments!

1 Like

So, I can’t test this because I don’t have a working Bisquixe. But

This is how hyperlink events are initially set up:

When play begins:
	set echo line events off;
	request glulx hyperlink event in main window;
	request glulx hyperlink event in status window.

And this is what happens after a hyperlink is clicked:

A glulx hyperlink rule (this is the default inline hyperlink handling rule):
	now the current hyperlink ID is the link number of the selected hyperlink;
	unless the current hyperlink ID is 0:
		cancel glulx hyperlink request in main window;[just to be safe]
		cancel glulx hyperlink request in status window;[just to be safe]
		follow the hyperlink processing rules;
	if the status window is the hyperlink source:
		request glulx hyperlink event in status window;
	otherwise:
		request glulx hyperlink event in main window.

In other words:

  • When the game starts, it requests hyperlink input in both windows.
  • When a link is clicked, it cancels hyperlink input in both windows.
  • Then, it requests hyperlink input in only one window.

So after clicking a link, all links in the other window should stop working.

Try this:

A glulx hyperlink rule (this is the replacement inline hyperlink handling rule):
	now the current hyperlink ID is the link number of the selected hyperlink;
	unless the current hyperlink ID is 0:
		cancel glulx hyperlink request in main window;[just to be safe]
		cancel glulx hyperlink request in status window;[just to be safe]
		follow the hyperlink processing rules;
	request glulx hyperlink event in status window;
	request glulx hyperlink event in main window.

The replacement inline hyperlink handling rule substitutes for the default inline hyperlink handling rule.

…of course, that only works if you have a version of Inform where “substitutes for” isn’t broken. If you have a broken version, just edit the default inline hyperlink handling rule in Simple Multimedia Effects.i7x.

2 Likes

Yery nice! That did it. Thanks!

I wonder if I should be making my own extension of fixes/updates. I think Mathbrush is planning to completely revisit everything this summer and may not want to update the extension before then.

1 Like

The revised inline hyperlink handling rule is listed instead of the default inline hyperlink handling rule in the glulx hyperlink rules. remains viable (though non-equivalent for rules listed in multiple rulebooks, of course).

2 Likes

No reason not to, once you’ve got a good few fixes together! I still need to mess around with the inline hyperlinking code to get rid of the dependency on Formatting Capture, which works very badly with Bisquixe.

1 Like

OK, for anyone who finds this in a search, I’ve rolled this and the original inline hyperlink code (along with a couple of other tweaks) into an update.

It can be found here