I wrote a Pharo program that generates my daily task non-stop.
The program itself works fine, however I always need to instantiate my object in the playground to run it. Is there some other way of doing it automatically without having to create an object and send a message to it?
Yes, you can. Save the image after you have instantiated your application and closed everything else. Then just start pharo from the image and you will have your application started.
If you want to do it more production wise you could use pharo-launcher.
For more detailed information you could squeak wiki which you can adjust to Pharo.
I would do one of three thing here:
Add an item to the World menu, so you can bring up the menu and select your task. See a Stackoverflow Answer on that same topic.
You could write some triggering code in a .st file on your file system, then use StartupPreferencesLoader to load it on startup.
Create a window morph with a button that, once pressed, runs your code. Open the window, quit and save image changes. Never close the window.
Related
first, I cannot attach my vi files, sorry. I'm not allowed, but I can attach snippets.
I've got a vi that opens and executes functions from a script file, and I'd like to be able to continuously click a button to reload the script file without having to restart the program. Currently the script file commands sit outside my main while loop and and uses a case statement to put the system in idle mode (manual control) when the button is not depressed before launching the program, or if it is, it will instantly open a dialog box looking for a script file upon program launch. I'd like to be able to open a script file numerous times during the execution of my program, but don't fully understand how, and this may be my own misunderstanding of what's going on with the code if I move it inside the main while loop. how is this best accomplished?
If you put your code outside of the loop, it is only executed once (very important: "dataflow"). You need to put the code into a loop to execute it multiple times.
You can insert the vi-snippet into your vi by drag&drop.
My vi contains two different options. You can change the vi as you need it, my vi is incomplete. I inserted a simple 2D-Array because I'm not sure if the vi you use after building the path is selfmade or given by LabVIEW.
For both options you should let the code run in some kind of state machine and use an Event Structure (I think you already implemented your program this way since you wrote about a main loop).
Version 1:
Everytime you click the button, the event is triggered and the code inside the event structure is executed.
Version 2:
Here you set a boolean if the button is pressed and handle the event with that value.
Since you wrote that you already have a main while loop, this option might be better four you. The first loop would be your main-loop, second one would be the loop in Version 2. You just need to add another case for the script to be loaded in.
VI:
I hope this is helpful for your problem.
Feel free to ask if you need more help or if you have any questions :)
Okay, I have had the most aggravating problem with OpenFileDialog1. I have a program that I've been using for some 8 months, and in the past month, the program has begun to hang randomly when utilizing the OpenFileDialog1.ShowDialog() function. I have already read through all of the other posts about multi-threaded vs single threaded application. This did not fix it. Enabling the "Show Help" button did not fix it. I am mostly at a loss. here is a thorough walkthrough of the bug:
Run the application. I can always use the Open File button a few times with no problems. It freezes randomly after the program has been running for awhile.
The freeze happens after I push the ShowDialog button, and never displays the Open File Dialog window. The entire program locks up and hangs. If I pause it, Visual Studio doesn't show an error. It underlines the OpenFileDialog1.ShowDialog() in green, which is very odd.
I have found a way to break the freeze. Simply run a second instance of the program and use the OpenFileDialog function. As soon as it loads the file in the second instance, the first instance unfreezes. However, this is not a fix.
The only thing I can think of that may be causing this is the program also uses a WebBrowser1 control. It only seems to happen AFTER the WebBrowser control, which is on a seperate form, not the main form, has been initiated and utilized. Does this make any sense at all?
Thank you for anyone who can help me. I am about to tear my hair out.
Debug your program with dnspy, And when the software freezes, you will be able to see within the dnspy the actual code even if it is in a third party DLL.
I have solved this problem. It was quite unsolveable based on my description above, but hopefully I will help someone with this solution. The error is related to using the IE11 Emulation Control (11000) in the WebBrowser1 control. For some reason this interferes with OpenFileDialog and causes it to hang. I have no idea why. I changed my WebBrowser1 to use IE9 Emulation Control (9999) and the error has gone away. Thank you to those who looked into this. This is a registry entry in HKEY_CURRENT_USER.
I am new to programming mac apps in Objective-C and need help with this. When I control click and drag to first responder from a button it brings up a box from which you can select some predefined functions that run when the button is clicked. On of the functions says newDocument. I was wondering if this means that it creates a new document (file) and if so how to actually make it create the file. I tried selecting newDocument but when I ran the app it said this: 2016-03-16 15:39:57.889 Test[26619:4382721] The (null) type doesn't map to any NSDocumentClass. My button is simply named create file and has no code attached to it, only the predefined function.
The method you are seeing, newDocument, is part of the Document Architecture. If you wish to use it you need to study the documentation, the particular function newDocument creates a "document" within your app along with an associated "window" rather than a "file" per se.
It sounds like you really need to read the Cocoa Event Handling Guide to learn how to handle a mouse event, and the File System Programming Guide to learn how to read & write files.
HTH
I'm opening a custom help file (CHM) using VBA and the api 'HtmlHelp', eg:
hWnd = HtmlHelp(Application.hWndAccessApp, sFile, HH_HELP_CONTEXT, context_id)
The Help file opens, but it's hidden behind the Access window, and although it's icon is displayed in the Taskbar, clicking the icon still does not bring it to the foreground - it remains hidden behind Access.
When I first started testing the Help file (on a Win8.1 machine), it opened correctly in front of the Access window, but now it won't. Does anyone have any suggestions as to what is causing this behaviour?
Some thoughts only - but be careful with the first hint:
Which purpose does the file hh.dat serve?
The hh.dat file stores user-specific information on all the HTMLHelp files (*.CHM) on your system (position, favourite topics, search history, etc.), and can cause a error if it has somehow been corrupted.
Delete or rename the file hh.dat to reset all (!) CHM windows on your system to their default settings.
You should find hh.dat in this directory:
\Documents and Settings\%username%\Application Data\Microsoft\HTML Help
Windows will create a new version of hh.dat when you next open any .chm file.
According to Microsoft's HTML Help API documentation (http://msdn2.microsoft.com/en-us/library/ms644703(VS.85).aspx):
Any help window that you create through the HTML Help API is owned by the calling, or parent, program. This allows the help window to stay on top of its parent, yet not be on top of any other program that has focus.
So the fact that the help window retains focus is actually the standard behaviour.
If you look at a typical HTML Help API call, you'll see that the first parameter specifies the "handle" of the window from which help is called:
HtmlHelp(hwndCaller,"YourHelpFile.chm",HH_HELP_CONTEXT,1001);
If the developer passes "null" rather than the window handle as the first parameter of the call, the help window is no longer owned by the calling program, and so does not retain focus. Here is an example of a modified call:
HtmlHelp(0,"YourHelpFile.chm",HH_HELP_CONTEXT,1001);
There's a drawback to this, though: when called in this way, the help window is no longer bound by the actions of the calling program. So if the user closes or minimises the program, the help window isn't closed or minimised as well.
I see you have hWnd – do you think you can add a code to send the help window to the foreground programmatically?
You can call SetForegroundWindow() to do the job. Someone has solved similar problem already, you just need to port call to SetForegroundWindow() or SetForegroundWindowNative() into the VBA.
EDIT: You report weird behavior that SetForegroundWindow() makes help window to flash only briefly.
Try issuing VBA's AppActivate command – it has helped someone else.
If this problem persists, you can try some workaround like resizing your app and help window to show them side-by-side.
So I am making an xcode application for OS X, and so far things have gone well. However, right now I am at a roadblock. My app is mostly one window, and I need that window to be created multiple times, in the way that apps like Safari, TextEdit, and all those ones have the File>New function. I am new at Xcode, and I was wondering if there was an easy way (hopefully 3-4 lines of code) to do this. If someone could explain that to me that would be great.
Thanks!
Start a new OS X project and choose "Create Document Based Application" . This will create a NSDocument subclass.
If you want to use Core Data , choose that also. This will create a NSPersistentDocument subclass.
This will give you the basis of your application with all the functionality you ask for.
Have a look at Document Based App Programming guide and NSPersistentDocument Class Reference
Whatever you do, dont try to bake your own. There lies madness.
The project template sets up the info.plist correctly to make this work.
Whatever I tell you, it won't involve only "3-4 lines of code," unfortunately.
If you're working from a non-document-based application, you'll want to factor out the code that creates your one window. If you're not using a window controller in concert with your window, you should implement one. Then you can implement an action that will create a new instance of your window controller, and so a new window. Of course, you'll need to add more infrastructure if you're interested in saving information associated with a window to a file.
Which leads me to your other option, which is to create a document-based application. The big advantage here is that, if you're interested in saving the window contents to a file, the infrastructure for doing so is provided. This involves starting over to some extent, but since you've already got the guts of your application working, you'd simply transfer those guts to the document subclass that is provided for you. You'd also need to provide to your project meta information describing the kind of document it is, including the file extension describing it.
Best wishes to you in your endeavors.