|
a remark that: my two functions are working well and give success or failure, my point of view is to make read these succes and failure to continue running other functions..
|
|
|
|
|
Have you checked proc.ExitCode ?
|
|
|
|
|
does not work for me build and publish operation writes console only "succeed" or "failed" keywords which i should take them consider.
|
|
|
|
|
How big are the batch files? Are we talking a few commands that you could execute yourself? If so, you've got more control and can get at the exit codes of the individual .EXE's that way.
If not, I'd probably look into setting an environment variable to an exit code your app can use instead of trying to parse streams.
|
|
|
|
|
My batch file is this:
-echo on
-cd C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
-TF get $/NECTARUP/Staging /recursive
-cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319
-MSBuild ProjectPath\Admin.Web.csproj /p:Configuration=Debug;PublishDestination=D:\deploy;AutoParameterizationWebConfigConnectionStrings=False /t:PublishToFileSystem /l:FileLogger,Microsoft.Build.Engine;logfile=C://Publish_LOG_Up.log
-pause
(This is simply for build and publish a project automatically on console with the help of msbuild command)
And the output of this commands are too big that written which files published and at the end it says 0 errors 0 warnings - succeeded!
So i should take consideration of the word "succeeded" to continuse to publish another project. If it failed then it should not proceed to publish anything further.
|
|
|
|
|
If you are automating it, you can start by removing the pause command and then check errorlevel.
|
|
|
|
|
i removed the pause command. the console closed after the operation ends. what/how do you think i can check error or success if i dont see any console by removing pause?
|
|
|
|
|
OK, now check the errorlevel -- just to be sure.
|
|
|
|
|
This is where the ExitCode property of the Process object you created would come in. The ERRORLEVEL in the batch file will be returned as the Process ExitCode.
Usually 0 means the last command ran without an error.
|
|
|
|
|
ExitCode doesn't work for batch files.
|
|
|
|
|
|
I goofed. I was trying to say the exit code from the .EXE should not propogate up to be the exit code of the batch file itself.
|
|
|
|
|
Of course it should; unless you handle it internally, which may be the case here.
|
|
|
|
|
Could be. We know nothing of what's in the batch file.
|
|
|
|
|
And it may be the case that the EXE always returns 0.
|
|
|
|
|
Dave Kreskowiak wrote: ExitCode doesn't work for batch files.
How so?
I ran the following test on windows 7 64 bit. I am fairly certain the following will work on any back to at least Win XP.
Batch file named DoitTest.bat, contents follow
@echo off
REM Test exit code value
exit 57
To test - open in a console window then run the following
cmd /K DoitTest.bat
echo %ERRORLEVEL%
Result is 57.
|
|
|
|
|
|
Hi,
I'm trying to keep my data access code separate from the code behind my form. What I am trying to do is populate my combo-box with a list of CompanyNames here's how I'm trying to bind this combo-box to my Companies entity to retrieve the CompanyName:
private void frmMain_Load(object sender, EventArgs e)
{
dal = new DataAccessLayer();
cmbCompanyNameSearch.DataSource = dal.GetcmbCompanyList();
}
and here's the method in my DataAccessLayer:
public List<Companies> GetcmbCompanyList()
{
if (entities == null) entities = new CompanySecretaryEntities();
ObjectQuery<Companies> companies = entities.Companies;
companies.MergeOption = MergeOption.AppendOnly;
var query = from c in entities.Companies
select c.CompanyName;
List<Companies> results = query.ToList();
return results;
}
This is giving me the following error:
Error 1 Cannot implicitly convert type 'System.Collections.Generic.List<string>' to 'System.Collections.Generic.List<CompanySecretary.Companies
Can anyone point me in the correct direction? I know if I change select c.CompanyName; to be select c; removes the error message but I only want to select c.CompanyName in this instance
|
|
|
|
|
select c.CompanyName is your problem. You are return a list of company names, not companies. Try
select c
Also the next problem you are going to have is with the ComboBox. Its only going to display the type of object "CompanySecretary.Companies". You'll need to check out the ComboBox's DisplayMember property to display the company name.
"You get that on the big jobs."
|
|
|
|
|
thank you for the reply, I have managed to get it working by changing the code behind my form to be:
List<Companies> companies = dal.GetCompanyList1();
cmbCompanyNameSearch.DataSource = companies;
cmbCompanyNameSearch.DisplayMember = "CompanyName";
cmbCompanyNameSearch.ValueMember = "CompanyID";
and renaming my DataAccessLayer method to GetCompanyList1
|
|
|
|
|
Hopefully this'll be a quick one to answer for me. I've found a process using the process class and I can use its handle to recursively process the child windows. After the recursion completes, it lists about 9 child windows. The process information's HandleCount is about 190 or so. It's possible that some information I'm looking for might be buried in those 190 handles.
Does anyone know how I can get a collection of the handles the process uses and how I can process each handle to see if its text property contains the string I'm looking for? If I can find the handle I'm looking for, I can put it in a IWin32Window object and then pass it to the OpenFileDialog constructor to ensure modality exists between it and the child form in the legacy application that needs to use it.
Putting it another way, the Process object has a HandleCount property but there's no method I can see that returns the collection of handles. If the Process object knows how many there are, it knows how to discover some information about them, no? I'd like to do something similar in my app but I can't find any appropriate methods, callbacks, etc that'll let me sit in the driver's seat. Any help appreciated.
|
|
|
|
|
Those nine windows will have sub-windows and controls. Each will have a handle - I think you'll have to loop through them using recursion.
Bastard Programmer from Hell
|
|
|
|
|
PHS241 wrote: Hopefully this'll be a quick one to answer for me.
Handle snooping is anything but quick.
PHS241 wrote: It's possible that some information I'm looking for might be buried in those 190 handles.
It sounds as though you're trying to make the OpenFileDialog in your app a modal child window of another app. I don't see this working as "modal" is a code flow control operation, but a window ownership one.
The handles you're seeing are not just for Windows and controls. They cover LOTS of other things, like DLL's, pens, brushes, other GDI objects, files, mutexes, threads, ..., the list goes on and on.
PHS241 wrote: If the Process object knows how many there are, it knows how to discover some information about them, no?
No. You can't find a method because there is no managed code method provided to do this. There is no collection of a processes handles and no exposed methods for getting one.
Handle snooping can be done as there are already lots of tools out there that can do this. BUT, it can only be done by an Administrator account. So if you're thinking of trying this in an application used by normal users, your idea is already dead in the water.
There is no "text" property of a handle. A handle is nothing but an identifier for an object. You then have to probe the object to find out what it is. But...
This is a NASTY procedure to go through to get at the handles of a process. You can find a C example here[^], about half way down the page, a post by AdaraCD.
|
|
|
|
|
I would have posted earlier as we found a quick solution. The app that launches the app that does the open and save file dialog needed to accomodate a number of possible apps calling it. We solved it by forcing the calling app to pass the window title it wants to attach modality to. The called app then receives the form title and then calls the API function FindWindow. The handle is 0 if no window exists or non-zero if it does in which case we know the handle reference. We construct a class derived from IWin32Window and pass the handle into it. Finally, we pass that object into the open and save file dialogs constructor. When the Show method is issued by the called app, the modality ties it to the window it was initiated from and voila, it all works as required.
I spent a bit of time trying to work out handle recursion which was thankfully not needed. I guess we had to jump through the hoops as part of the process. If I remember, I'll post a code snippet tomorrow in case anyone else wants to know of a possible solution. It might not be ideal or super-efficient but it works and with customers snapping at our heels it was a good outcome.
|
|
|
|
|
If anyone's interested here is what we did, first the issue:
We have an engineering package (off the shelf) that runs fine on XP but under some conditions hangs on 7. We isolated the problem to the open and save dialogs. We wrote an exe containing the open and save dialog controls. That worked fine, but it wasn't modal. After some research, the calling app now shells the exe and passes its window title into it. We get the handle of the form containing the title we're looking for and that gets passed into the open and save dialog controls. This establishes a modal link between caller and called exe. Without this, the exe would be launched fine but if you clicked somewhere else you lose the exe's form (it doesn't appear on the taskbar) and that puzzles the users. What we've achieved works around the 7 problem. As I alluded, it might not be ultra efficient but it works okay for us on 7 so take it or leave it! No, I cannot post the complete code but the following snippets should get you started.
1. Define the api function to get a window title:
[DllImport("user32.dll", EntryPoint = "FindWindow", SetLastError = true)]
static extern IntPtr FindWindowByCaption(IntPtr zeroOnly, string windowName);
2. Use it to get the handle of a window containing the title you're looking for. Note, IntPtr.Zero forces the search by title alone.
IntPtr ip = FindWindowByCaption(IntPtr.Zero, windowTitle);
3. Define a class deriving from IWin32Window.
internal class WindowWrapper : IWin32Window
{
private readonly IntPtr _hwnd;
public WindowWrapper(IntPtr handle)
{
_hwnd = handle;
}
public IntPtr Handle
{
get {return _hwnd;}
}
}
4. Assign the handle (IntPtr) from 2 above into an instance of WindowWrapper (3).
WindowWrapper ww = new WindowWrapper(ip)
5. Finally, use the wrapper in the constructor of the file dialog to establish a modal link between calling form and the executable.
OpenFileDialog ofd = new OpenFileDialog();
if(ofd.ShowDialog(ww) == DialogResult.Cancel) blah blah blah.
Obviously, you don't need to do this if you're using the dialogs in your own forms but it's a possible get-out-of-jail card if you need to connect disparate processes.
|
|
|
|