I've got the below code:
// Initiate the font choosing lists.
var headerListWindow = Titanium.UI.createWindow();
var headerFontListData = [{title:"Row 1"},{title:"Row 2"},{title:"Row 3"}];
var headerFontList = Titanium.UI.createTableView({data:headerFontListData});
chooseHeader.addEventListener('click', function(e) {
headerListWindow.left=win.width;
var a = Titanium.UI.createAnimation();
a.left = 0;
a.duration = 1000;
headerListWindow.add(headerFontList);
headerListWindow.open(a);
});
headerFontList.addEventListener('click', function(e) {
var a = Titanium.UI.createAnimation();
a.left = win.width;
a.duration = 1000;
headerListWindow.close(a);
});
Which slides a window in nicely. When I open headerListWindow for the first time, everything appears, the list works, and the window slides in nicely. When I close() the window, however, all the list elements' names revert to "R.". Then, upon reopening the window, the list elements are completely gone. Why is this?
.close() kills your window. it's passed on. this window is no more. It has ceased to be. It's expired and gone to meet it's maker. It's a stiff. Bereft of life. It rests in peace... etc.
when your window is closed, then your are destroying it. You might like to try .hide() instead which will not null the window, but just not show it on the screen.
blissapp, I am using the Alloy framework, and if I do a window.close() it does not kill the window. It closes the window, but if I log the window after it's still defined, and its definitely not dead.
I am not sure wether this applies to developing without alloy or not, but the object remains. You do have to re-open the window in order to render it, but it is my experience that the window is not deceased as you put it. I am definitely not destroying it.
An example:
welcome.addEventListener('open', function() {
console.log("welcome is open");
win1.close();
Ti.API.debug(win1);
});
Outputs:
[INFO] : welcome is open
[DEBUG] : [object welcome]
Ofcause Nulling the variable is a solution, but why doesn't .close() work as it is suposed to according the documentation using Alloy? Am I missing something when working in Alloy?
Related
I have a UWP app. I want to be ale to create new windows from the app, but any subsequent window needs to be a specific smaller size compared to the main window. I don't do anything with regards to sizing the main window and let the OS take care of sizing it for me.
I bring up a new window like this:
auto window = CoreApplication::CreateNewView();
window->show();
void NewWindow::show() {
auto currView = ApplicationView::GetForCurrentView();
currView->PreferredLaunchViewSize =
Windows::Foundation::Size(float(options.width), float(options.height));
currView->PreferredLaunchWindowingMode = ApplicationViewWindowingMode::PreferredLaunchViewSize;
currView->SetPreferredMinSize(Size(20,20));
Xaml::Window::Current->Activate();
ApplicationViewSwitcher::TryShowAsStandaloneAsync(
window_->id(),
ViewSizePreference::Default,
window_->parentId(),
ViewSizePreference::Default);
}
When the main window comes up, it comes up just fine. When I click on a button which gets to this function, the new window comes up in the same size as the main window. I reopen the app, but now the main window shows up in the size I wanted the new window to show up in. Then clicking the button to bring up the new window brings up the new window in the size I wanted it in. So I am a bit confused. Am I setting the sizes the right way? Is there anything else glaringly wrong here?
As # Raymond Chen said, PreferredLaunchViewSize set the size when the app launches, it will change the size of your main window. And you can use ApplicationView.TryResizeView method to set the size of new window.
For example:
auto parentView = ApplicationView::GetForCurrentView();
auto newView = CoreApplication::CreateNewView();
newView->Dispatcher->RunAsync(Windows::UI::Core::CoreDispatcherPriority::Normal,
ref new Windows::UI::Core::DispatchedHandler([this,parentView]()
{
int newViewId = 0;
Windows::UI::Xaml::Controls::Frame^ rootFrame = ref new Windows::UI::Xaml::Controls::Frame();
rootFrame->Navigate(Windows::UI::Xaml::Interop::TypeName(MainPage::typeid), nullptr);
Window::Current->Content = rootFrame;
// You have to activate the window in order to show it later.
Window::Current->Activate();
newViewId = ApplicationView::GetForCurrentView()->Id;
IAsyncOperation<bool>^ mytask = ApplicationViewSwitcher::TryShowAsStandaloneAsync(newViewId);
auto deviceEnumTask = concurrency::create_task(mytask);
deviceEnumTask.then([this](bool res)
{
// set the size of new window
ApplicationView::GetForCurrentView()->TryResizeView(Size(600, 320));
});
}));
I'm creating a small non-modal dialog in TornadoFX like this:
find<Grib>(scope).apply { openModal(block = true,
owner = FX.primaryStage,
stageStyle = StageStyle.UTILITY,
modality = Modality.NONE) }
How do I go about setting (and retrieving) it's window position for later? That is, I have a preferences object for the window location and I want to update it so that the next time the user opens the window, it opens in the same place they last closed it.
I was able to mostly solve my problem by digging through some of the TornadoFX source code.
I added this to my init{} function:
Platform.runLater {
root.scene.window.x = Main.preferences.getDouble(GRIB_WINDOW_X, 400.0)
root.scene.window.y = Main.preferences.getDouble(GRIB_WINDOW_Y, 400.0)
}
And then adding this to my close() function:
Main.preferences.putDouble(GRIB_WINDOW_X, root.scene.window.x)
Main.preferences.putDouble(GRIB_WINDOW_Y, root.scene.window.y)
This "mostly" solves the problem in that it does save/restore the window position, however the window flickers when it is created as it moves from some default position to the newly set position.
At this point, I'm sure this is something simple that I'm missing but I can't for the life of me figure it out.
Working on an InDesign script that takes text passed into the script and writes it into the currently selected text area.
insertButton.onClick = function(){
var postIndex = postList.selection.index;
var postContent = posts[postIndex].content.rendered;
$.writeln(app.selection[0].parentStory.contents);
app.selection[0].parentStory.contents = postContent;
$.writeln(app.selection[0].parentStory.contents);
myWindow.close();
}
I've confirmed that the function is getting called correctly, that postContent exists and is what I expect it to be and that the first writeln call dumps out the current value of the TextArea. The second $.writeln never fires, so I know the error is on
app.selection[0].parentStory.contents = postContent;
Is there an updated way to set TextArea contents that I haven't found in documentation?
Thanks in advance!
I think your problem is that your window is modal thus preventing any interaction with inDesign objects.
You have to quit the dialog first in order to modify objects:
var w = new Window('dialog');
var btn = w.add('button');
btn.onClick = function() {
w.close(1);
}
if ( w.show()==1){
//"InDesign is no longer in modal state. So you can modify objects…")
}
...postContent exists and is what I expect it to be...
Indesign expects a string here --> is it what you expect as well?
What is an input selection? text? textFrame?
You could
alert(postContent.construction.name)
to ensure what you've got
Jarek
When debugging was enabled in ExtendScript Toolkit, I was able to find the error being thrown:
"cannot handle the request because a modal dialog or alert is active"
This was referring to the dialog I opened when I initiated the script.
Delaying the text insertion until the dialog has actually been closed fixed the issue.
insertButton.onClick = function(){
var postIndex = postList.selection.index;
postContent = posts[postIndex].content.rendered;
postContent = sanitizePostContent(postContent);
// The 1 here is the result that tells our code down below that
// the window has been closed by clicking the 'Insert' button
myWindow.close(1);
}
var result = myWindow.show();
// If the window has been closed by the insert button, insert the content
if (result == 1) {
app.selection[0].parentStory.contents = postContent;
}
I use a script which opens the story editor like this:
app.menuActions.itemByID(119793).invoke();
How can I close it programmatically? How can I detect whether it's opened or closed?
A story editor window may be closed with its close method.
Here is a function which closes the story editor window if it's open. It tests for the presence of a zoom property on the window to determine whether the window is a story editor or not (Thanks Loic Aigon for this idea)... There must be a better way of doing this but I haven't found it.
function closeStoryEditor() {
var windows = app.activeDocument.windows,
nbWindows = windows.length,
i,
closedWindow = false;
for (i = 0; !closedWindow && i < nbWindows; i += 1) {
if (!windows[i].hasOwnProperty("zoom")) {
// Let us presume that a window without a zoom method is a story editor window...
windows[i].close();
closedWindow = true;
}
}
}
To close it, it's…the same call ! if you want to check if the editor is already opened, you can loop through all open windows like this :
app.activeDocument.windows.everyItem().name;
and see for matches.
Loic
http://www.loicaigon.com
I noticed that in Windows, if you maximize a window you can not resize it until you un-maximized it again. This appears to be a normal behaviour, so I would like to remove my resize gripper when the window is maximised.
At the moment I can't find a property to detect if a window is maximized, and although I could add a boolean in my controller, it wouldn't necessarily catch requests to maximize from the OS.
So if you know of a reliable way to test if a window is maximized please let me know.
On a related note, I am using custom chrome, and when I maximize a window it overlaps the windows task bar. I can think of hacks to detect available screen size (using a transparent system chrome window), but it would be good to know of a better method.
Thanks
Rob
In your application (MXML) on the in the init method you ussually call on creationComplete:
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
creationComplete="init()" >
Add the following code:
this.addEventListener(NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGE, trackState);
the method looks like this:
public function trackState(event:NativeWindowDisplayStateEvent):void
{
if (event.afterDisplayState == NativeWindowDisplayState.MAXIMIZED)
{
isMaximised = true;
} else {
isMaximised = false;
}
}
I have figured out how this can best be done thanks to some pointers from TheBrain.
Firstly you need to watch for resize events to the window your want to control:
NativeApplication.nativeApplication.activeWindow.addEventListener(NativeWindowBoundsEvent.RESIZE, onWindowResize);
Then handle that event to decide if the window is maximised or not:
public function onWindowResize(event:NativeWindowBoundsEvent):void
{
if (event.afterBounds.height >= Screen.mainScreen.visibleBounds.height && event.afterBounds.width >= Screen.mainScreen.visibleBounds.width)
isMaximised = true;
else
isMaximised = false;
}
You then need to catch or create your own maximize button, and when clicked perform the following code:
if (isMaximised)
{
var bounds:Rectangle = Screen.mainScreen.visibleBounds;
NativeApplication.nativeApplication.activeWindow.bounds = bounds;
}
else
{
NativeApplication.nativeApplication.activeWindow.bounds = new Rectangle(100, 100, 500, 600);
}
You can modify the bounds to over maximize (which is handy for custom chrome windows with shadows), and you can also set the application to reset to a default size if the maximize button is clicked when it's already maximized (or do nothing).
I had issues about when to assign the window resize listner, and ended up removing and adding it every time the maximize button was clicked. It's a bit of overkill, but not too bad.
There is Win32 API Call that will do this for you:
BOOL IsZoomed( HWND hWnd );
to get the actual usable space from the screen, use the flash.display.Screen class, or you can use the systemMaxSize() which returns the largest window size allowed by the OS. For maximization you have some events that the window is dispaching when maximized/minimized/restored. You can find more info on the adobe pages (the link under systemMaxSize).
To detect if window is maximized...I don't think there is such a function (I might be wrong) but you can test if the app size is equal with the available screen size which means it's maximized. Or hook on the resize event which is triggered when the app is maximized/minimized/resized
Here is an easier way of checking if a window is maximized:
if(stage.nativeWindow.displayState == NativeWindowDisplayState.MAXIMIZED)
{
//do something
}
The following worked for me. No need to set event listeners, this code can be used to check the real-time state of the native window:
if (nativeWindow.displayState == 'maximized')
{
trace('Maximized');
}
else
{
trace('Minimized');
}
Can you use something like this to hook the maximize() event?