I created .isf form file in ISN studio. In my main.au3 file I have included this form (#include "Forms\main.isf"). But when i hit run nothing happens. Do I have to add somenthing in my main.au3? (I'm pretty new with AutoIT)
Also when I look into code which form generates there is:
$btn1 = GUICtrlCreateButton("Button",170,70,100,30,-1,-1)
GUICtrlSetOnEvent(-1,"onBtn1Click")
shloudn't be there $btn1 instead of -1 in the second line?
Thanks :)
You need to make it a user defined function (UDF). That won't work because a UDF needs to be a .au3 file. I'm not familiar with ISN studio, however to include a UDF you need to do this.
#include "C:\path\myfunctions.au3"
Also if the UDF is in the same location as the script you can just use the relative path like this.
#include "myfunctions.au3"
Here is are some example UDF's.
http://www.autoitscript.com/wiki/User_Defined_Functions
You have done nothing wrong; just forgot something.
It's correct to include the .isf file in your script. So the GUI is already present, just hidden! You only need to show it using: GuiSetState(#SW_SHOW, $HANDLE_OF_YOUR_GUI).
Then you should see your GUI! As an example see the "Testproject" in ISN AutoIt Studio.
Related
I want the content to remain a text file, so code such as:
Approvals.Verify("some actual result as text");
Should continue to work. But I would like the approval tests to write to a ..approval.csv file or a ..approval.log file instead of ..approval.txt file.
I looked through the code and I think I may need to create a custom IApprovalWriter, but I also notice that the ExtensionWithDot property is read/write, so I'm wondering how this can be set.
Does anyone know how to do that?
ApprovalTests.Approvals.Verify(WriterFactory.CreateTextWriter(text, fileExtensionWithoutDot));
or for your example:
Approvals.Verify(WriterFactory.CreateTextWriter("some actual result as text", "log"));
Happy Testing!
I'm trying to get these parameters while creating a visual studio template but it doesn't return a value, it just stays like this:
string rootnamespace = $rootnamespace$; // this is the output, it just stays as it was declared
string SpecificSolutionName = $SpecificSolutionName$; // this is the output, it just stays as it was declared
According to msdn - Template Parameters:
SpecificSolutionName:
The name of the solution. When "create solution directory" is checked, SpecificSolutionName has the solution name. When "create solution directory" is not checked, SpecificSolutionName is blank.
And I made sure that the "create solution directory" is checked, but still it doesn't give any value.
How can I get these values. please... ?
I also found $SpecificSolutionName$ to be broken. As a work around it turns out the directory of the solution is usually the same as the name of the solution and thus:
If your solution template has only 1 project: the solution and project names are identical and thus you can simply use $projectname$ in lieu of the broken $SpecificSolutionName$.
If your solution template has multiple projects (aka ProjectCollection): add the attribute CopyParameters="true" to the desired ProjectTemplateLink element and use $ext_projectname$ in lieu of the broken $SpecificSolutionName$.
I think the documentation is not enough clear when it comes to multiproject templates. Putting the wizard declaration in the vstemplate of your multiproject definition, and on the project/s that you desired to use to, makes the "broken" variable appears.
This is because, it launch the wizard for each time you declare it, so to speak, and it behaves differently depending on the context.
Pay attention: the variable $SpecificSolutionName$ only has value when executing the first time for the multiproject vstemplate declaration, and only executes RunStarted, ProjectFinishedGenerating and RunFinished methods. So, to use it in a global context you need to figure out some kind of mechanism to mantain the value between Wizard executions, as adding a new key in the replacementsDictionaryor something.
Hope this help.
I fixed this by adding this doctype declaration to the start of my .vstemplate.
<?xml version="1.0" encoding="utf-8"?>
The doctype declaration is not supplied by the template wizard, but is present in all the preinstalled templates. Good luck and thank you for your patience while I researched this question.
$SpecificSolutionName$ is always empty. How can I tell if the user is making a new solution directory or not?
Frustratingly, the docs are wrong in 2 ways.
There is no "SpecificSolutionName". It is "SpecifiedSolutionName".
If the user unticks "Create directory for solution", then $SpecifiedSolutionName$ is not blank as stated; it actually becomes the same as $projectname$. How you determine when this has or has not occurred and whether what you're reading is a unique solution folder's name or not, is another story.
I am looking for a way to separate the repetitive html codes from web pages, and for this I am planning to use the macro functionality. The problem here is for every macro I need to put this macro in a file, or put some of them in a file and include this in the template file.
What I need is to include once just the directory name something like
<#import "/tags/widgetDirectory" as widgets />
here the /tags/widgetDirectory is a directory , and every files here can be seen as a macro defined.
when I need to insert a code part from a file from this directory lets say slide.ftl I will just use
<#widgets.slider />
the system will check for slider.ftl in the /tags/widgetDirectory directory . here the slider.ftl can have <#macro> as first and as last line , or these can transparently added and system can load it as a macro
this will easy my designer work.
Maybe there is better way for doing this kind of widgets/components based web design ?
best regards,
This feature (importing directories) is something that's planned for FM actually... but it won't happen anytime soon. But I guess it can be solved fairly well with a hack right now. Instead of #import, use your own TemplateMethodModelEx, that you could use like <#assign widgets = importDirectory('/tags/widgetDirectory') >. This will return a TemplateHashModel that's also implemented by you and is bound to the directory path. When an item of that hash is get, it uses Environment.getCurrentEnvironment().include. The included file is expected to create a macro with name __main or something. So then you get that variable with Environment.getCurrentNamespace().get("__main") and return it as the result of the hash lookup. Of course this hash should also maintain a cache, so that if the same item is get twice, it wont include the template for the second time, just return the macro extracted earlier. This can be developer further, so that if the include file didn't define __main, then it's supposed that it prints directly to the output, and so it will be included again, when the "tag" is called again.
I am using Rstudio and not sure how options "run" and "source" are different.
I tried googling these terms but 'source' is a very common word and wasn't able to get good search results :(
Run and source have subtly different meanings. According to the RStudio documentation,
The difference between running lines from a selection and invoking
Source is that when running a selection all lines are inserted
directly into the console whereas for Source the file is saved to a
temporary location and then sourced into the console from there
(thereby creating less clutter in the console).
Something to be aware of, is that sourcing functions in files makes them available for scripts to use. What does this mean? Imagine you are trying to troubleshoot a function that is called from a script. You need to source the file containing the function, to make the changes available in the function be used when that line in the script is then run.
A further aspect of this is that you can source functions from your scripts. I use this code to automatically source all of the functions in a directory, which makes it easy to run a long script with a single run:
# source our functions
code.dir <- "c:\temp"
code.files = dir(code.dir, pattern = "[.r]")
for (file in code.files){
source(file = file.path(code.dir,file))
}
Sometimes, for reasons I don't understand, you will get different behavior depending on whether you select all the lines of code and press the run the button or go to code menu and chose 'source.' For example, in one specific case, writing a gplot to a png file worked when I selected all my lines of code but the write failed to when I went to the code menu and chose 'source.' However, if I choose 'Source with Echo,' I'm able to print to a png file again.
I'm simply reporting a difference here that I've seen between the selecting and running all your lines and code and going to code menu and choosing 'source,' at least in the case when trying to print a gplot to a png file.
An important implication of #AndyClifton's answer is:
Rstudio breakpoints work in source (Ctrl-Shift-S) but not in run (Ctrl-Enter)
Presumably the reason is that with run, the code is getting passed straight into the console with no support for a partial submission.
You can still use browser() though with run though.
print() to console is supported in debugSource (Ctrl-Shift-S) as well as run.
The "run" button simply executes the selected line or lines. The "source" button will execute the entire active document. But why not just try them and see the difference?
I also just discovered that the encoding used to read the function sourced can also be different if you source the file or if you add the function of the source file to your environment with Ctrl+Enter!
In my case there was a regex with a special character (ยต) in my function. When I imported the function directly (Ctrl+Enter) everything would work, while I had an error when sourcing the file containing this function.
To solve this issue I specified the encoding of the sourced file in the source function (source("utils.R", encoding = "UTF-8")).
Run will run each line of code, which means that it hits enter at the beginning of each line, which prints the output to the console. Source won't print anything unless you source with echo, which means that ggplot won't print to pngs, as another posted mentioned.
A big practical difference between run and source is that if you get an unaccounted for error in source it'll break you out of the code without finishing, whereas run will just pass the next line to the console and keep going. This has been the main practical difference I've seen working on cleaning up other people's scripts.
When using RSTudio u can press the run button in the script section - it will run the selected line.
Next to it you have the re - run button, to run the line again. and the source button next to it will run entire chuncks of code.
I found a video about this topic:
http://www.youtube.com/watch?v=5YmcEYTSN7k
Source/Source with echo is used to execute the whole file whereas Run as far as my personal experience goes executes the line in which your cursor is present.
Thus, Run helps you to debug your code. Watch out for the environment. It will display what's happening in the stack.
To those saying plots do not show. They won't show in Plots console. But you can definitely save the plot to disc using Source in RStudio. Using this snippet:
png(filename)
print(p)
dev.off()
I can confirm plots are written to disc. Furthermore print statements are also outputted to the console
Somebody gave me a testing program to write records into the windows event log (but I don't have the sources). I understand the general way of writing and reviewing event log, but that program behaves very special in a way that I can write records, that have a source which does not exist.
There is not even a registry entry in .../eventlog/application, hence no formatting libs.
If I try that from my own code, I can write such a record but the Windows Event Viewer then always tells me something about "description cannot be found" (which is correct and I understand why that happens).
The question is now: Since that foreign test prog CAN do it, it must be possible somehow - but HOW?
Many thx!! :-)
OK, finally I found it (also, got the sources) - the prog creates the registry entry (probably happens when calling CreateEventSource()), it was just not visible until refreshing regedit :-|
And, it DOES register a formatting lib, only that it is something I cannot rely on: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
Or, can I?
Ah, here we go for an explanation:
Difference between EventLog.WriteEntry and EventLog.WriteEvent methods
So, I cannot, as I'm not using .Net ... :-|
Now, if I NOW send another event from MY prog (with the same, newly created source, as the foreign prog), I see it in the event viewer normally.
That means, WriteEntry() actually does not write a different/special type of evt log record containing the text directly (contrary to the standard method of writing just a msg catalog ID + params) but rather there must be some trick in the formatting lib to make the EventViewer apply some kind of "default" formatting.
Any ideas how I could accomplish this? Except just copying the EventLogMessages.dll above? :-)
OK, finally found an answer about this one in http://msdn.microsoft.com/en-us/magazine/cc163446.aspx
"This file is called EventLogMessages.dll, and it contains 65,536 event descriptions, each of which consists of the string "%1", a placeholder for whatever string you want to write"
I was hoping for something like "messageid=*" but that seems to be too simple :-|
But maybe somebody else is interested in whats happening here ...