Related
i have been trying a code found here to add rating bar but i got an error on
cb.setToggleButton(
where the "setToggleButton" method didn't or doesn't exist anymore
any idea if it has been update cause the post i tagged was back from 2014
That method doesn't exist, it should be setToggle(true). Notice in the linked post it just said setToggleButton( without even a closing bracket. Since this was written a while back I'm guessing I just switched a desktop to check the method name and got distracted then forgot to fix that. Hazards of blind coding without the comfort of an IDE.
#devcrp actually wrote the correct answer before but unfortunately he deleted it. If he undeletes it his answer should be accepted.
I am trying to display a logo on top of a video played with libvlc (2.0.2). I tried to find some documentation, but I had no luck. Here is the best attempt I could come up with:
libvlc_video_set_logo_string(m_player->core(), 1, "logo_1365886316.png"); //logo file path (I've also tried logo_1365886316.png,0,5000)
libvlc_video_set_logo_int(m_player->core(), libvlc_logo_x, 500); //x-coordinate
libvlc_video_set_logo_int(m_player->core(), libvlc_logo_y, 100); //y-coordinate
libvlc_video_set_logo_int(m_player->core(), libvlc_logo_opacity, 255);
// I've tried with the following, but I had no luck.
//libvlc_video_set_logo_int(m_player->core(), libvlc_logo_repeat, -1);
//libvlc_video_set_logo_int(m_player->core(), libvlc_logo_delay, 6000);
libvlc_video_set_logo_int(m_player->core(), libvlc_logo_enable, 1);
What is happening is that my logo is visible for few milliseconds or so, and then it disappears. If I try to initialize logo again, nothing is showing up. Also, if this is important, I am initializing logo after video has been started.
I don't know why this is happening. As per various forum posts, I am doing everything ok, and I am not initializing anything on the stack so it can be freed after I exit init function.
It's not broken! It's working for me. You have to add the option --sub-filter=logo to your options array that you pass to libvlc_new().
The official VideoLAN forum seems to provide the answer you needed: the logo feature is probably broken in VLC 2.0.X (source).
Also, another thread on the same forum seems to confirm that you are doing the right thing when you wait for the video to be playing to display the logo (at least, you know it does not come from you).
I think you simply should consider the feature broken for now and hope someone will provide a patch someday. Unless you feel like writing this patch by yourself.
EDIT: And by the way, I checked the vlc-devel mailing list from the date of the forum message (october 2012) to today, and did not find anything about a possible patch. The only thing that I found about the logo functions was a message stating that some other logo-related feature appears not to work since 2.0.3 (which was also the version cited in the forum post I shared in this message).
I'm posting this to basically continue a thread that was closed:
"Error trying to open a VS 2010 project in VS 2012 : Type universe cannot resolve assembly" by user1766173
I've dug deeper into the issue and narrowed some things down, so hopefully the discussion can be resumed.
I'm using VS 2012 (and I don't have 2010 to compare to). My solution, "TWConsole", was working fine on Friday, and as of Tuesday it was not. Both versions compile and run fine, but in the designer, no XAML file in the project can be opened without crashing. However, opening an XAML from a different project within the same solution works fine. Everything I've googled regarding this issue results in someone dealing with a 3rd party assembly.
However, in my case the assembly that can't be resolved is my own--the one generated by the build.
Interestingly, I've found that by "secretly" replacing the TWConsole.exe in the bin\Debug folder with from last monday's build, everything works! ... that is, until I rebuild the solution, and that exe gets replaced, and then the XAML designer begins crashing.
So there's something relating to new code I've added that is somehow "infecting" the main assembly. In the meantime before anyone can come to my rescue with a solution, I will start with the last-working solution and just add one line of code at a time until the problem surfaces, so as to pin-point the exact cause.
Thanks
EDIT:
I've been able to narrow down the source of the problem to one line of code:
public static bool GetFavWashPkgs(out List<WashPkg> wPkgs)
If I remove the "out" keyword, then compile, the designer crashing problem is resolved. Same applies to the "ref" keyword--also a no-no in this case. I have tried for an hour to re-create this anomaly in a more basic test, using a test class and test function, but to no avail. All I can report is that this "sensitive" function is overloaded, the custom class WashPkg has the attribute [serializable()], and the class in which this function resides is static. If I modify the function declaration so that the type of List is int instead of WashPkg, the problem is also resolved.
So at this point it's still a mystery as to why the designer doesn't like that function declaration.
Is there a way to do some checks before allowing a merge in Mercurial?
I have found the pre-update hook and have a script that runs before an update is allowed, by adding the following to ~/.hg/hgrc:
[hooks]
pre-update = ~/hg_pre_update.sh
But I'd like to run the check before allowing a merge as well, and currently it just allows the merge to go through without running my checks.
Background
In case there are alternative ways to solve the problem...
We have been having a number of problems with 'lost' edits under Mercurial. I've tracked down most of them now to the same underlying cause: someone has vim edit sessions open while either they or someone else does a hg update or merge. The editor warns the file has changed externally, the user ignores the warning and saves their changes.
When these changes are committed, for Mercurial there is nothing controversial. The user has simply reverted all the changes brought in with the last update and put in their own changes.
Some time later, we notice the code has gone walkabouts. Cue assorted insults flung the way of mercurial...
Set vim to autoreload changes if no local changes where done. (otherwise ask, or force a merge)
that's how I avoid such issues in any editor...
Sorry just worked out there is a pre-merge hook that works just the same as pre-update. I tried it before asking the question, but now just looking at my hgrc I realise I put the script being called for that hook to ~/hg_pre_merge.sh which doesn't exist.
I can't find the existence of pre-merge documented anywhere but still feeling like a bit of a muppet now.
In the last few years I've encountered "ghost files" in Netbeans, but I didn't have proof of it, so I had to live with it and when I tried to explain the situation, it's hard to believe, now I have proof of it and it's a show stopper, any fix for it ?
It goes like this, I have a Java class that I've been using for many years, sort of a tool, I add a bit as I have more experience, but once in a while, after I added a new method, and used it in another class, Netbeans couldn't recognize it, it seemed to me Netbeans was still looking at the old copy of the class where the newly added method didn't exist. And yet if I copied this updated class to another project, the new method works fine and Netbeans can find it. In NB 6.7 it just acted like the class froze in time, any new additions to it wouldn't be recognized, now when I tried it in NB 6.9 I could catch the "ghost" !
It happened by accident, yesterday after I updated the class, I tried to use the new method in another class in the same project, the red flag went up, it couldn't find the new method, so I moused over the new method call, and right clicked on it, "Navigate" => "Go to source", bang the ghost showed up ! If I do this in NB 6.7, it just rang a bell as if it's telling me it couldn't find it. But in NB 6.9 it goes to the "source" which is not my java class source file[Get_Time.java], it's another generated file, so I moused over the opened "ghost" file name in the editor, the name was "C:\Users\USER.netbeans\6.9\var\cache\index\s117\java\14\gensrc\Get_Time.java(read-only)", the content seemed like a skeleton of my source file Get_Time.java , but definitely different, and I am pretty sure it's this "ghost file" that's been causing problems.
During the course of development I occasionally changed the system time to test different functions in the class, could this caused the ghost file to mess up, if I change the current time to 2016 and modified the source file, then NB might record the file last changed in 2016, and if I change the time back to 2011, and add a new function, it wouldn't accept it, because it might compare the dates of different versions of source file and stick with the "latest time stamp" ?!
I wish NB never keep ghost files, "Always Use The Actual Source File", this would avoid a lot of such problems. I did try to delete that ghost file, but the next time I compiled, it's generated again. I don't want to delete too much content from "C:\Users\USER.netbeans\6.9...", it might mess up my NB setting. Anyhow, it's now a show stopper, I can't add more changes to the class, it's frozen in time, what's the fix ?
Just some suggestions as I got stung by this problem before.
Did you built a jar and added dependency to this jar manually?
e.g.
1) project A is packaged into A.jar with a class Time.
2) project B depends on A.jar and project A
3) Time.java in project A is changed
4) project B will not see the changes as it'll always read from the A.jar built before the change happen.
Try deleting NetBeans' cache (~/.netbeans/6.9/var/cache/index/ directory) when you go back to the future and forward to the past. NetBeans is probably getting a bit confused by the file timestamps. Since it is somewhat of an edge case to be hopping around dates like that, I doubt it would be something NetBeans would give a high priority in attempting to fix/handle.