Circuit client in my app subscribed to event 'formSubmission':
client.addEventListener('formSubmission', function (event)
Until last days it works fine, but now it doesn't trigger.
I tried to test it by creating a simple app that just send a form (just one button on it) as a reply to user's message and should log form submissions, but it doesn't go on this function.
client.addEventListener('formSubmission', function (event) {
var submittedValue = event.form.data[0].value;
console.log(`[CIRCUIT]: Form was submitted.`);
};
Any other events like 'itemAdded' or 'itemUpdated' work as they should
Yes, just confirmed this is a bug and is being worked on. Will post here when its resolved. Are you using the circuitsandbox.net or production?
Production systems have been updated and the formSubmission event is received again. circuitsandbox will be updated with this fix soon.
Related
Having a time with notifications again after upgrading to the new version of RN (again)...
This function never gets called. It doesn't matter if I have requestPermissions:true or not
PushNotification.configure({
onRegister: (tokenResponse) => {
console.log("AppNotifications::onRegister", tokenResponse);
}
...
if requestPermissions:false, I call after logging in:
PushNotification.requestPermissions( (response) => {
console.log('NotificatoinsState::requestPermissions', response);
});
...which also does absolutely nothing.
Couple things that always get asked in all these threads:
Xcode capabiltity for Push Notifications is added
Developer.apple.com has the right certs and they are not expired
I'm running this on a device, not the simulator...
I've tried to have the PushNotification.config in both a state as well as completely outside of the React component lifecycle, both are the exact same
Not sure what configuration I'm missing here, but any help would be super.
Opened this ticket as well in case this gets figured out in one spot or the other:
https://github.com/zo0r/react-native-push-notification/issues/1052
On a deadline, so I'll keep trying stuff and if I find the answer, I'll put it here too..
Nevermind. I forgot to update the AppDelegate.m file...
https://github.com/react-native-community/react-native-push-notification-ios
Works fine now.
The post has been rewritten to better fit the current problem.
I have a button x:Name="selectVesselButton". On button click, it tries to establish a connection to a server, which takes a sec or two for to do. Originally, I wanted the button to be grayed out while it was downloading and deserializing the json file from the connection.
My old code (before async, and trying to update the button):
// disabling the button to prevent spam clicking.
string buttonText = selectVesselButton.Text;
selectVesselButton.IsEnabled = false;
selectVesselButton.Text = "loading...";
// retrieve data for speed page.
RetrieveData();
// redirect to next info block if build was successfull.
FocusSpeedblock();
// enabling the button again.
selectVesselButton.Text = buttonText;
selectVesselButton.IsEnabled = true;
The issue with this code was that the button visuals did not update until the RetrieveData() was finished, defeating the purpose of doing that at all. This was because the code for updating the interface and the code for downloading and deserializing the object were both on the same thread.
However, following Ivan's advice, I made the downloading and deserializing Async, which fixed this issue (more like moved it).
This works fairly well, but I am still having some trouble updating the interface automatically. I have some labels that need to be updated based on the json file output. The value of the labels update on the background, but only update visually once I interact with the labels (I.E. scrolling the scrollview they are on). Check edit 3 for more detail on that.
EDIT 3:
When the second thread is finished, it should call the UpdateSpeedLabels() and update some labels. However, they update in codebehind, without instantly updating the interface. They only update if I interact with those labels.
The preferred way of doing this on Xamarin is with data binding. As you opted out of this it is still possible.
What you need is to ensure that your long task is not running in the UI thread as it blocks it and prevent its updates. You do this by using Task.Run(() => { your task code }); . However you can't update your user interface inside the Task.Run as it is not running on the UI thread and it would crash the app, so you need to use Device.BeginInvokeOnMainThread(() => { your UI code }); inside Task.Run for that part.
I'm successfully using Soundcloud's widget API, except the setVolume() method is broken :(
First, I love the widget, but I'm blown away that after all that amazing work there is no volume control available! People will immediately "back button" out of my site when they hear 100% audio and I can't alter it using setVolume()... I have to get it working or pull it :(
Here is what is happening, I have an instance named "widget" (which loads and plays well on the page).
widget.bind(SC.Widget.Events.READY, function() {
$('#audioIndictments').removeClass('remove'); // This disables a CSS rule, making the soundCloud iframe visible
widget.setVolume(10); // This should set the volume to 10% but doesn't :(
widget.getVolume(function(vol){
console.log(vol); // This outputs 0.1 in the console :/
console.log(widget); // This outputs the object in the console and I don't see anything out of whack :|
});
widget.play(); // This successfully fires up the widget and the audio begins playing :)
widget.setVolume(10); // Just to see if it makes a difference, after the play() method, I ran setVolume again after the play() method and still no change :(
widget.getVolume(function(vol){
console.log(vol); // This still outputs 0.1 in the console :/
});
});
Strange results. I found another blogger who asked a similar question and got no satisfactory answer. What's the deal here? What am I not seeing?
Thank you for taking the time :)
Try using the a volume between 0 and 1. This fixed it for me.
0.25 = 25% volume
I too am facing the same issue and I discovered that the volume does not reset to full when setVolume method is called outside of the READY event. This is why the setVolume button on the SC api playground works since it's called externally. But there is another problem - when the next track in the playlist is loaded into the widget, it resets the volume back to full and as a result, deafens the user.
I've used a hacky workaround until this is fixed.
Setup a new PLAY_PROGRESS event and call the method inside there.
widget.bind(SC.Widget.Events.PLAY_PROGRESS, function() {
widget.setVolume(10);
});
The setVolume method will continuously be called when the track is played. Not ideal but it works.
If you have a slider in place for volume then you may use this instead:
widget.bind(SC.Widget.Events.PLAY_PROGRESS, function() {
var vol = jQuery('.slider').val();
widget.setVolume(vol);
});
I have random crashes in my WinJS application when navigating between pages.
The problem is that these crashes never occurs when the app is attached to the Visual Studio debugger; so I can't find where they come from.
I use the WinJS.Application.onerror event to prevent crashes, and log what happens, but as this works well when I try with a random exception, my "uncatchable" crashes doesn't seem to fire this event (I don't have anything logged).
Do you have any idea of what could cause these crashes, or any solution to find more informations ?
Sometimes errors can't fire the WinJS.Application.onerror for several reasons (in my app, the problem was in an iframe, in a page not using winjs).
When it happens, errors can be found in the event log, under "administrative events"
Found this on this link :
http://www.davepaquette.com/archive/2012/09/15/windows-8-store-app-crash-logs.aspx
Jason gives a good solution to this problem in this video (start at time 14:48). In his example, the app was crashing if you had a callback and navigated to a different page before the callback completed. Could this be the case for your app? Any more details on what is going on when you navigate?
For others (since it seems you already know about this!):
To be able to debug easier, use the WinJS.Application.OnError event. Wire up an event handler that dumps out information about the problem before the app crashes.
WinJS.Application.onerror = function (info) {
var err = {
errorMessage: info.detail.errorMessage,
errorUrl: info.detail.errorUrl,
errorLine: info.detail.errorLine,
errorCharacter: info.detail.errorCharacter,
};
Windows.Storage.ApplicationData.current.localFolder
.createFileAsync("crash.txt", Windows.Storage.CreationCollisionOption.openIfExists)
.then(function (file) {
Windows.Storage.FileIO.appendLinesAsync(file, [JSON.stringify(err)]);
});
};
The final stop for exceptions in JavaScript is actually window.onerror; not every exception will get thrown through WinJS.Application.onerror. Try hooking window.onerror directly.
I have console applicaiotn that currently uses CAsyncSocket.
I need to implement SSL so after some searching I found this project: http://www.codeproject.com/Articles/3915/CAsyncSslSocketLayer-SSL-layer-class-for-CAsyncSoc
For some reason same simple code that works fine on GUI code does not work in console app.
Has anyone exp. with CAsyncSslSocketLayer ?
Thanks.
CAsyncSocketEx uses a window as a sort of cheap thread to handle the event notifications that come from select(). Unfortunately, if you don't have a message loop, then the window which it creates will not receive these events.
http://support.microsoft.com/kb/90975
This article explains that a call to CreateWindow() needs to be called from a thread which has a message loop. And if you don't, then anything sent via PostMessage() won't get there.
I've recently started to tinker with this -- I want to remove the annoying hidden window and replace it with a normal thread. Their code relies on WSAAsyncSelect() in order to receive socket events... to a window. Yuk!
It's been a while since I had the same problem, but if I remember correctly, to use CAsyncSocket in a console app you need to add something like DECLARE_CONSOLEAPP (first two links shown below) to your console app. This should give your console a message pump to generate the socket notifications (OnReceive, etc.) GUI apps have these pumps but console apps don't, generally. The third (msdn) link below might also apply, it has more info and a different way.
If these still don't work, you should put breakpoints in your socket code and make sure your socket isn't instantiated in a thread or callback other than the main console app (the one that now has the message pump).
I think googling around for 'CAsyncSocket WinApp' or 'CAsyncSocket console app' would show more.
http://www.codeguru.com/cpp/misc/misc/consoleapps/article.php/c243/Console-app-using-MFC.htm
http://troels.knakkergaard.dk/code.htm
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/a6f1b72a-21d8-4046-a3dc-d7d29ece2ef6