I know the script to do this is:
local StarterGui = game:GetService('StarterGui')
StarterGui:SetCoreGuiEnabled (Enum.CoreGuiType.Chat, false)
and
local StarterGui = game:GetService("StarterGui")
StarterGui:SetCoreGuiEnabled(0,false)
but what kind of scripts do these go in and where do I put the scripts?
Use it in a LocalScript. The wiki page clearly states:
This item should be used with a LocalScript in order to work as expected in online mode.
Source: http://wiki.roblox.com/index.php?title=API:Class/StarterGui/SetCoreGuiEnabled
If you don't know where to put the scripts, you should go over the basics on the wiki: http://wiki.roblox.com/index.php?title=Intro_to_Scripting
(It doesn't really tell you where to put LocalScripts, but on the page of LocalScript it certainly clearly does)
Related
I'm running tests with Matchstick and my save() calls don't seem to be working (I set up my tests by saving some entities, but then my application code doesn't see them when it goes to load).
Is there any way to check the current state of the backend and see what's in there? Mainly just trying to troubleshoot.
Turns out, you just have to read the docs
https://thegraph.com/docs/en/developer/matchstick/
logStore()
I'm trying to figure out how to get flash messages to work in Hanami. The only reference to flash messages that I've found in the official docs are about testing, not actually implementing. If I overlooked something, please point me in the right direction.
I also found the Hanami::Action::Flash class in the source, but haven't been able to discern from that what I'm doing wrong.
So, I forked the official bookshelf demo app and added what I think is a super rudimentary demonstration of the flash message not working as I think it should, based on what I've read, immediately after creating a book. I feel like the message added in the create action should be visible in here somewhere, but all the index page shows (immediately after the redirect), is...
<div id='flash'>#<Hanami::Action::Flash:0x7f442c865408 {}></div>
<div id='message'></div>
What am I doing wrong? Thanks!
do you have sessions enabled? flash is exposed by default as you're using Hanami 1.1.
Then set it in the action flash[:some_notice] = "Test" and use it in a template.
regards,
Sebastjan
You can programmatically invoke services if you already know the name of the service. As best I understand, the Services menu is built by calling a validation method on each published Service.
Is there a way to access a list of installed Services without using the Services user dialog?
EDIT: I don't mean background processes. I am talking about the items in the Services menu in Finder. Overview of what they are here.
There is an API provided by Apple, documented here - https://developer.apple.com/documentation/coreservices/launch_services
Note that you need to have your service registered in system database and consuming code needs to know about its existence.
I hope this helps.
The somewhat supported (but poorly documented) approach is to call lsregister and parse the output. The output does not have a documented or guaranteed format, however.
You run it this way for the commandline:
LSREGISTER="/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister"
${LSREGISTER} -dump
(Yes, it's deeply buried and not in PATH.)
This dumps a ton of information. You just want services, which look like this:
--------------------------------------------------------------------------------
service id: FileMerge/Compare To Master (0x16f8)
menu: FileMerge/Compare To Master
port: FileMerge
message: diffVersusMasterService
timeout: -1
send types: "NSFilenamesPboardType"
The part you want is the "menu" tag:
$LSREGISTER -dump | grep ^menu: | cut -c 29-
Obviously you can parse this more directly in code, but the only way I know of that's even vaguely supported is to run lsregister.
OK, that's obnoxious. If you're willing to use private APIs, it's pretty straightforward. Define an interface for LSServiceRecord:
#interface LSServiceRecord
+ (id)enumerator;
- (NSString *)localizedMenuItemTitle;
#end
And then you can enumerate over them to get the menu titles:
id enumerator = [LSServiceRecord enumerator];
for (id item in enumerator) {
NSLog(#"%#", [item localizedMenuItemTitle]);
}
You might find the portName property helpful. It's the name of the application that registered the service. You might also find +[LSServiceRecord enumeratorForContentsOfPasteboard:] useful if you're trying to limit it to valid services.
If you want to explore more, I recommend Hopper, and looking in LaunchServices framework.
try launchctl list, see https://guide.macports.org/chunked/reference.startupitems.html for some more info,.
I'm using Zombie.js for testing with Cucumber-js, and I can't seem to get my client side scripts to run.
Visiting the page:
this.browser.visit("http://localhost/boic",function(e, browser,status,errors){
console.log('status',status);
console.log('error',errors);
console.log('console',browser.text("H1"));
});
Returns a status of 200, no errors, and displays the H1 text correctly. However, if I include a script to change the H1 code in the page:
<script>
$('H1').html('hello world');
</script>
The H1 text remains unchanged, and no global variables are accessible via browser.window...
thanks!
Did you load jQuery in your page before the script is called?
there is also the runScripts browser option but that defaults to true.
But I'm gonna recommend running an external phantom.js process and going through the webdriver interface. Just because I spent 6 months trying to get zombie to do what I wanted and phantomjs made it all easy. http://phantomjs.org/release-1.8.html https://github.com/LearnBoost/soda
I agree w/ Jon Biz. Zombie is difficult to work with. Many sites that use JS libraries that might contain minor errors cause it to crash (I think node fails) when the zombie browser encounters them - if you have the runScripts option set. This makes it very hard to use for any application/site that requires external JS - ie most of them.
I also recommend switching to Phantomjs.
I'am obviously new to Google Apps Script, nevertheless I have some experience in coding in C, PHP and Java. Since we would like to create a small CRM in our company with Google Apps Script, we need to create an application with a form available on Google Sites. I've been searching an answer for this problem a long time, I haven't unfortunately found any answer. I have a code like this:
var klienci_id = new Array(100);
var klienci_nazwa = new Array(100);
var klienci_adres = new Array(100);
var klienci_osoba = new Array(100);
var klienci_telefon = new Array(100);
var klienci_email = new Array(100);
function doGet(e) {
var app = UiApp.createApplication();
// hello world label
var helloworldLabel = app.createLabel("I love Apps Script!").setStyleAttribute("fontSize","16px");
// add the label to the app container
app.add(helloworldLabel);
return app;
}
function main() {
var klienci = SpreadsheetApp.openById("0ArsOaWajjzv9dEdGTUZCWFc1NnFva05uWkxETVF6Q0E");
var kuchnia_polska = klienci.getSheetByName("Kuchnia polska");
var dane = kuchnia_polska.getRange("D7:F22");
doGet();
}
And everytime I try to publish it and enter the given link I get the error "Unknown macro doGet". I know this is a common problem when somebody doesn't use doGet() function but I do - and it still doesn't work. I also believe that Google should create a thorought documentation on Google Apps Script, which would work the way the Unix manual does, since I just cannot get through all these strange pages of goddamn help :) It's neither a Windows help, nor a good manual ;)
Regards,
Kamil
I have a suspicion that you made a "version" once, published the app, went to the "real" link and not the "development" link, and then added the doGet() function. When you make a version, it freezes the code at that time. The version that the app is published at is the version of the code that will run at the "real" link (what you give users), which allows you to keep editing the code without disturbing existing users of your app. There is a special "development" link given to you in the publish dialog that always refers to the most recent version of the code, but which will only work for you and no one else.
I'm affraid there is a little misunderstanding on your side concerning the use of the 'doGet()' function. When you want to run an application as a webapp, the doc says indeed that it must contain a doGet function but what it doesn't say explicitely is that this function is supposed to be the starting point of the whole app, ie the function that the url will call in the first place. So it doesn't make much sense to have the doGet function called from a so called "main" function since the "main" function is not the main function...
I cannot imagine right now a situation where some function calls the doGet function since every function in the script is called initially (directly or indirectly) from this doGet function.... in fact the 'end' of any other function in the script 'returns' to the doGet initial function. Well this is maybe not absolutely true in every case but it gives you the general idea about how it works.
I'm hoping this is clear enough and, to return to your code snippet, if you remove the doGet(e) call, it will ideed show a nice "I love Apps Script!" but it will never do anything else, certainly not see the "main" function.
I've copied your code here https://script.google.com/macros/d/MJ80AK8t7kbgDcC-NaLPYvH797_hv7HHb/edit?template=app&folder=0AKGkLMU9sHmLUk9PVA
and when deployed as a web app appears to work https://script.google.com/macros/s/AKfycbxOiaukLt7P4pIm7bms7aU16uEo6FuZ-MNOh0tSqUwr/dev
Only thing I can think of is there is something else in your code not copied into the snippet that is throwing the exception.
[Just before the GUI Builder was published I came up with Creating a framework for custom form interfaces using Google Apps Script which might help you with your project]
Thank you both for help. Serge, yes, it's really not obvious what the structure of Google Apps Scripts should be. They are based on JavaScript, however, due to lack of HTML in the code they have completely different flow - so naturally, there has to be a main function which is executed first. And of course in every programming environment it has to have a different name to make it more distinguishable ;-)
I created a new copy of my application, not changing the code completely - deployed it and it works beautifuly. Since I haven't changed anything in access options, it's quite strange that two applications with the same code and the same options don't give the same result. I think it may be a kind of the environment flaw, maybe someone from Google should look at this :)
Here's the link to the script, I've set access to "Anyone with the link".
https://script.google.com/a/macros/foodbroker.pl/s/AKfycbwk2IM-rIYLhQl6HOlbppwGOnw4Ik_kH7ixbaSNVxIE-QR7cq8/exec