|
Look at your code:
static void Main(string[] args)
{
wifixmlWriter.startDocument();
Thread th = new Thread(new ThreadStart(background));
Console.WriteLine("starting thread...");
th.Start();
th.Join();
wifixmlWriter.endDocument();
Console.WriteLine("press any key to quit");
Console.ReadKey();
}
You are breaking into a thread and arbitrarily ending the document. You need to synchronise with the thread so that endDocument() is not called until all the elements have been written.
I must get a clever new signature for 2011.
|
|
|
|
|
thx dude 
the problem was in the root element ( i forgot the root xD when starting the xmlDocument )
its working now thx 4 help 
|
|
|
|
|
You are not writing / creating any root element[^]for the XML. Please create the XML in specified format.
"Never put off until run time what you can do at compile time."
- David Gries, in "Compiler Construction for Digital Computers", circa 1969.
|
|
|
|
|
thx dude ^^ i forgot the root element xD
in main i call "starElement"
public void startDocument()
{
txtWriter.WriteStartDocument();
txtWriter.WriteStartElement("Trace");
}
and i write the data in writeElement method like this
public void writeElement(string element, string data)
{
try
{
lock (thislock)
{
txtWriter.WriteStartElement(element);
txtWriter.WriteEndElement();
}
}
catch (InvalidOperationException e)
{
Console.WriteLine("erreur :" + e.Message);
}
}
thx again ^^ 
|
|
|
|
|
I see no need for a lock in this code. Every writeElement call is made from the same thread, so you do not have to synchronize it. However, making th.Start() followed by th.Join() does not make too much sense to me... It will work as if it was synchronous.
|
|
|
|
|
thx for this informations ^^
|
|
|
|
|
Hi All,
I've got a strange issue that I need a little help with, I'm completely stumped at the moment.
There are functions in my application to allow users to select a file in the UI and then either open it in an editor application or open Windows Explorer with the file selected.
public void LoadFileInDefaultEditor(AppLaunchArgs args)
{
var processStartInfo = new ProcessStartInfo(args.ApplicationExePath)
{
Arguments = "\"" + args.Path + "\"",
WorkingDirectory = Path.GetDirectoryName(args.ApplicationExePath),
Verb = OpenVerb
};
try
{
Process.Start(processStartInfo);
}
catch (Exception ex)
{
Log.Error("Failed to start " + args.ApplicationExePath, ex);
}
}
This is all working as expected when I run in debug/release from within VS. If I copy the release build to any location on the machine and launch the app it also works as expected.
As soon as I build the installer and run the install (built using Inno Setup) and run the installed version these functions aren't working.
I have an older installer for the same application, if I install this one the functions work as expected this part of the source code hasn't been touched between these two different versions / installers. The Inno build script is also identical between the two installers.
Any pointers on this would be great, I'm really at a loss as to where to go from here.
Thanks in advance,
|
|
|
|
|
It would help if you clarified your statement that the functions are "not working."
What is the exact error? Where exactly is the error occurring?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
This is it ... there is no error. Nothing turns up in the logs and no app instance is started.
|
|
|
|
|
Well, the first thing I would do is put in a bunch of logging statements that document more of what's going on.
For instance, I would log the application exe path that you are creating at the beginning of the function you showed, just to make sure it is what you expect it to be.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I think this is worth trying now as I have utterly run out of ideas.
Surely since the *exact* code is in the old version of the application and remains unchanged between versions it makes no sense why it has automagically stop working ...
Thanks,
|
|
|
|
|
Where are you installing it to? (Meaning an "All Users" installation, or per User)
Ran into a similar thing...set it up to make an app All Users, but forgot to make the files readable/writeable to them. Setup put them in the correct place, but without the correct permissions. No errors, but no workee, either.
If using Inno, you'll need the "Permissions: users-modify;" flag in the file copy lines.
|
|
|
|
|
Damn, this is a hot lead!! I had a feeling the problem was in the setup somewhere. I asked about this on CP and the inno setup list back in December (yes I've been on this problem for a while).
Did you change your setup based on moving your app to Win7 compatibility?
The app is compiled as 32bit as there are some third party components that are 32bit (and various other issues) so it's installed into the "Program Files (x86)" directory and there is an "All Users" option on the installer UI which I've been using to test this. I think this may well be the answer.
You might be interesting in the app I'm making as well ... it's for muso's!
http://www.jamsoft.co.uk/[^]
I'll get on this tonight and give an update here. Thanks!
|
|
|
|
|
Jammer wrote: Did you change your setup based on moving your app to Win7
compatibility?
Mine was Win7 to begin with...just never noticed a problem until I actually tried it after an install...just ran it from VS or otherwise directly from the location VS output the files.
|
|
|
|
|
Jammer wrote: You might be interesting in the app I'm making as well ... it's for
muso's!
That is so....strange.
My app is very, very similar in concept. More generalized and without some of the more advanced features, but...damn.
Great minds, thinking alike?
|
|
|
|
|
I'd like to think so ... but then being maverick is kinda appealing too 
|
|
|
|
|
Hmm ... unfortunately this hasn't fixed it either. I've also tried "Permissions: everyone-modify;"
Back to the drawing board. Thanks GenJerDan
|
|
|
|
|
Looking at it again, a question:
That function looks to me like it is opening the selected file in its default program, yes?
If so, why not just do
System.Diagnostics.Process.Start(SelectedFile);
and let windows itself do the grunt work?
|
|
|
|
|
on a Digital Audio workstation there maybe many editor apps and many apps with file associations to the .wav extension for instance, I need to be able to be specific about the app.
It's been working fine for multiple releases of my app, then all of a sudden it's stopped working.
I'm thinking of ditching Inno Setup and trying to build a new installer using WiX ...
|
|
|
|
|
The suddenly stopped working part is probably Win7.
The only way to track it down will be to create a debug build that logs every step of the problem area to a file saved in a public directory, then install it under a "normal" user account.
|
|
|
|
|
Indeed, that is my conclusion as well.
|
|
|
|
|
Also when asking on the Inno Setup list I was told not to add this Permissions tag to the files ...
|
|
|
|
|
Really? What kind of sense does that make? If the app is running with the credentials of someone without permission to those files...it won't work.
|
|
|
|
|
I was thinking the same thing.
To be honest, I've decided to move to WiX for my installer. I'm going to create a new installer from the ground up. I've been meaning to do this since I started using WiX at work a few months ago, I prefer it in almost every way.
If the problem persists with the new installer I'll be closer to a solution!
I've started this same discussion on the Inno Setup newsgroup a few times now and a few suggestions are made and then the thread goes dead and I'm no nearer a solution. Time to really shake things up I think.
Thanks for all your help chap.
|
|
|
|
|
Jammer wrote: Time to really shake things up I think.
Almost always a good idea. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
