|
Because Access uses a date/time datatype and not seperate date and time types. If you provide only the date it will automatically use a default time and vis-vesa.
Just ignore them and read the date or time as appropriate. Or else store the date and the time as strings. Or if the problem is with how things look in Access you can specify the format within Access itself (but it will still be stored with a date and a time).
|
|
|
|
|
Hi there,
I'm quite exhausted now trying to directly set the Scan0 Paramater of a Bitmap to avoid slow copying bitmaps in memory.
Basically, I try to do the following:
1.) I have a buffer containing already loaded Bitmap files in memory. Fo r performance reasons, this buffer is allocated via VirtualAlloc and therefore unsafe.
2.) I'm passing a UnmanagedMemoryStream with a subportion of the buffer to my Drawing function, pointing to the beginning of the bitmap file.
3.) I'll try to instantiate a bitmap, using the Streampointer to use the buffer directly and draw it to the screen ( or better, a backbuffer).
This looks like this:
<br />
<br />
unsafe<br />
{<br />
UnmanagedMemoryStream mstr= new UnmanagedMemoryStream((byte*)buf.ptrStart.ToPointer(), buf.Count, buf.Count, FileAccess.Read);<br />
}<br />
BitmapData bmd;<br />
<br />
BufferBitmap = new Bitmap(1920, 1080);<br />
<br />
ImageLockMode fLock = ImageLockMode.UserInputBuffer;<br />
<br />
bmd = BufferBitmap.LockBits(new Rectangle(0,0,1920,1080),<br />
fLock,PixelFormat.Format24bppRgb);<br />
unsafe<br />
{<br />
bmd.Scan0 = new IntPtr(mstr.PositionPointer+14);<br />
}<br />
<br />
BufferBitmap.Unlock(bmd); <br />
<br />
GfxBuffer.Graphics.DrawImageUnscaled(BufferBitmap, new Point(0,0));<br />
<br />
Well, all I get is a "Invalid Parameter" Exception when setting the LockBits with the UserInputBuffer Flag, or, if I use the ReadWrite Flag, I would probably have to use the buffer the Bitmapobject manages, which would be an unnecessary copy operation. I just want to display the bitmap I've already in memory which the smallest possible effort.
Does anybody have an idea whats going wrong here ? According to some examples I found, it should work this way. Interestingly, even if a try to pass a buffer allocated with Marshal.AllocHGlobal the LockBits operation fails...
The buffer contains valid data, because this code works, but I think, this causes every time an instantiation and copy procedure:
<br />
<br />
Bye,
Florian
|
|
|
|
|
Hey Ya'll.. I'm building a little analyzer utility that will analyze text files automatically. Currently you have to click the Open Files button to load a file to analyze.
I'd like to mod this program so that if you double click the file you want to analyze, it will spawn the analyzer and automatically analyze the contents of the clicked file.
I've set my PC to always Open With the analyzer when you click on the files with my extension, but I'm at a loss on how to get the filename / path of the file that spawned it.
Can anyone point me in the right direction?
Thanks in advance
-Chris
|
|
|
|
|
Chris,
I'm going to assume that you've set the file type in Folder Options in Explorer to load your application automatically. In the Advanced dialog, you get the command line to run. Using %1 on the command line should give you the FQ path to the file that was double-clicked.
Change
"c:\program files\myapp\myapp.exe"
to
"c:\program files\myapp\myapp.exe" %1
Make your Main() into Main(string[] args), and args should contain the path/file that was clicked on.
Stephan
|
|
|
|
|
Got it.. Seems to be working great!
Thanks a lot!!
-Chris
|
|
|
|
|
It should be passing the filename as the first argument to your app.
void Main(string[] args)<br />
{<br />
}
Current blacklist
svmilky - Extremely rude | FeRtoll - Rude personal emails | ironstrike1 - Rude & Obnoxious behaviour
|
|
|
|
|
What was working is now not! I'm not exactly sure where the problem resides, but after I built my installer, and installed the application on my PC everything seemed to be fine.
Then when I click the log file to analyze, it keeps opening back up using notepad.
So I went to Open With.., and browsed to my .exe, and checked the option to always open files with this extention. When I double click the file now I get a critical error stating that the LOG file I double clicked and it's path is not a valid Win32 Application.
How do I reset the target so that when I click the log file, it uses my .exe as the application?
|
|
|
|
|
Hi,
I am developping an Add in in C# with Visual Studio 2005 for Excel 2003 and I have a problem when Garbage collector is called for freeing memory. Let see a little example to explain the problem.
first test:
I have created a tool bar with a simple button, here is the code of the Click button events :
private void test_Click(Office.CommandBarButton cmdBarbutton, ref bool cancel)
{
string[] test = new string[10000000];
for (int i = 0; i < 10000000; i++)
{
test[i] = very long string ;
}
}
after the process was executed once, I click a second time the button and then see with Process Explorer that a new thread called "CreateApplicationContext" is created in Excel process and I never can click again on my button (test_Click is never executed again).
the second test i have done is to put this 2 lines at the end of my click event code:
test = null;
GC.Collect();
so after GC.Collect() is called the same thread is created and I can't click again on my button.
So, I am sure that in first test, it is the implicit call to the Garbage collector that crashs my functionnality.
DOes Anyone have any info about this issue?
|
|
|
|
|
Hi everybody
I'm currently experimenting with design patterns, one of them is the design pattern. First some code:
This will init my application, it will init itself then by switching from state to state
static void Main(string[] args)
{
ScreenInitState startState = ScreenInitState.GetInstance();
Console.WriteLine("All states exited");
Console.WriteLine("Press any key to exit.");
Console.ReadKey();
}
Here we switch from state to state
abstract class InitState
{
protected void Switch(InitState state, bool bStopSelf)
{
if (bStopSelf)
Stop();
}
abstract protected void Stop();
}
class ScreenInitState : InitState
{
private ScreenInitState()
{
Switch(InputInitState.GetInstance(), true);
}
}
class InputInitState : InitState
{
private InputInitState()
{
Switch(SoundInitState.GetInstance(), true);
}
}
So the app starts like this:
Main -> SreenInitState -> InputInitState -> SoundInitState -> ...
Now when I'm in the last state, do all previous states still exist in memory or are the collected by the GC? Though this pattern is very useful I'm concerned about memory usage here. Does anyone know what happens to the objects during runtime?
regards
-- modified at 9:54 Tuesday 6th June, 2006
modified 12-Sep-18 21:01pm.
|
|
|
|
|
What's behind SoundInitState.GetInstance()? Every time I've written something with an Instance property or a GetInstance(), it's been a singleton. If all of your states are singletons, the GC isn't collecting them. Also, what does Stop() do in each of the states?
You'd need to be designing something pretty complicated to warrant singleton states. In general, states work better as flyweights. I'd say use structs, but they break the inheritance model.
|
|
|
|
|
Stephan Samuel wrote: What's behind SoundInitState.GetInstance()? Every time I've written something with an Instance property or a GetInstance(), it's been a singleton.
Correct, that's the case here
Stephan Samuel wrote: Also, what does Stop() do in each of the states?
Just a function where the state will cleanup itself (remove resources etc) before switching to the next state
Stephan Samuel wrote: the GC isn't collecting them
So you suggest to use some sort of structs + switch-calls to keep the memory footprint as small as possible? Or does it help to design my states as normal instances instead of singletons?
modified 12-Sep-18 21:01pm.
|
|
|
|
|
You should keep your states small. Structs won't work because they don't implement inheritance, but try to keep the information inside your concrete state classes to a minimum. I would avoid the singleton pattern for states.
Currently, your states don't really switch. Each tunnels through to the next. There should probably be one top-level controller (it may be a singleton but may not need to be) that decides which state you're in and runs the states:
(Please pardon any typos or syntax errors; I'm making this up as I go.)
<br />
public class MyController<br />
{<br />
State currentState;<br />
<br />
public void RunMe()<br />
{<br />
while (this.currentState != null)<br />
this.currentState = this.currentState.RunMe();<br />
}<br />
}<br />
<br />
public abstract class State<br />
{<br />
public abstract State RunMe();<br />
}<br />
<br />
public class ConcreteState1()<br />
{<br />
public RunMe()<br />
{<br />
return new ConcreteState2();<br />
}<br />
}<br />
<br />
public class ConcreteState2()<br />
{<br />
public RunMe()<br />
{<br />
return null;<br />
}<br />
}<br />
Likely, you'll want to pass around some objects, and your states will pass out different "next state" objects as RunMe() returns based on what those objects look like. Each state lives only as long as it's executing, so there's no memory overhead. If you're worried about setup/tear-down performance of your state objects (e.g. -- if they have a complicated DB open process and you need them to run really quickly with persistent connections), consider some level of factory for the states: either have a connection factory, give each state its own factory and let it decide when to create a new one of itself, or create a factory class (or implement one in MyController) that decides the lifetime of your state objects.
I'd also implement IDisposable and the C# disposal pattern for each of your state objects to clear up unmanaged resources. Managed resources should get cleaned up automatically.
The other way to implement this is to have MyController decide which state is next based on the state of some object. My personal belief is that method isn't as good. It's less OO: you might as well just code all the possibilities within the controller and forget the states.
|
|
|
|
|
Great. The Controller object really makes sense and keeps memory overhead at a minimum, that's a really good way, I like. The only addition I will make is to keep a Stack<State> in my controller, so that some states will still be able to overlap each other, like a menu on top of a game.
Thanks a bunch! 
modified 12-Sep-18 21:01pm.
|
|
|
|
|
As you are switching from state to state by using a method in each object, the objects can't be garbage collected. The Switch method of each previous state is still executing until the last state is finished. When the last state returns from the Switch method, all previous Switch calls will finish in turn and release the objects.
This is not a problem, however, as long as you make the Stop method release all objects contained in it's state object.
---
b { font-weight: normal; }
|
|
|
|
|
Guffa wrote: This is not a problem, however, as long as you make the Stop method release all objects contained in it's state object.
That's what I do. So the only thing left in memory will be the instance of the state objects and nothing more? I hope this isn't too much overhead as a drawback for clean design.
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Greeeg wrote: So the only thing left in memory will be the instance of the state objects and nothing more?
If you get rid of all references in the object (setting them to null), all objects that it used are up for garbage collection. If the memory is needed, they will be collected.
---
b { font-weight: normal; }
|
|
|
|
|
Hello,
In order to show users a string representation of a 120kb file in Hex-format within a windows forms textbox I wrote a simple routine that converts all decimal bytes in a buffer into a hexadecimal string, taking formatting into account. The routine looks like this:
<br />
int x =0;<br />
<br />
string content = String.Format("\n{0:X5}: ", x);<br />
<br />
for (; x < Data.senderdata.Length; x++)<br />
{<br />
content += String.Format("{0:X2}", Data.senderdata[x]);<br />
<br />
#if DEBUG<br />
flp.setProgress(0, Data.senderdata.Length, x);<br />
#endif<br />
<br />
if ((x + 1) % 2 == 0) content += " ";<br />
if ((x + 1) % 16 == 0) content += String.Format("\n{0:X5}: ", (x+1));<br />
}<br />
When done, the content string is assigned to a textbox control. Perhaps I should mention "senderdata" is a byte array.
The routine seems to take an insane amount of time to complete. I realize that it might take a few secconds, since senderdata.Length typically has a value of about 125K, but this is taking over a minute to complete, in a single threaded program running on a pentium 4. Is this due to the String.Format Hex-conversion routine or is it just that it's too hard for Windows to handle such long strings? Does anyone have a tip to improve on the performance of this?
Thanks in advance for any help,
Benny
|
|
|
|
|
One possible suggestion is, you could replace the variable type of content, from string to StringBuilder instance.
StringBuilder's concatenation are faster than string's.
-- modified at 9:48 Tuesday 6th June, 2006
|
|
|
|
|
Thanks very much (Stefan aswell), this helps alot
|
|
|
|
|
I think a main issue is the mass number of string concatenation. As a string is immutable, a new string object is created everytime you append something to your content variable. Try using StrinBuilder[^] instead.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook
www.troschuetz.de
|
|
|
|
|
When the += operator is used on a string, it might appear like the string is appended to the end of the original string. This is not true, as strings are immutable in .NET.
The statement:
content += " ";
is actually performed as:
content = string.Concat(content, " ");
With that in mind, let's do some math to find out why the routine is so slow:
Each iteration does either one, two or three concatenations. The first one is done every iteration, the second is done every other iteration, and the third is done every 16th iteration.
This gives that:
:: Each iteration does by average 1.5625 string concatenations.
:: Each iteration adds by average 3.0625 characters to the string.
With an array containing 125000 elements it produces a string that contains about 383000 characters. As each character is two bytes, that gives a string that uses 766 kbyte of data.
As the string is growing in a linear fashion, we can calcuate the average work done by each concatenation by taking the average size of the string during the operation, which is half the size of the finished string.
So a concatenation is by average moving an amount of 383 kbytes of data. As we have 125000 iterations, we have around 195000 string concatenations (125000 times 1.5625). 195000 times 383 kbytes makes 74685000 kbyte.
When the routine has finished, it has moved somewhere around 75 gigabyte of data. (As that is far more than the amount of avialable RAM, this has also caused hundreds of garbage collections to take place.)
That is the reason why the routine is so slow.
To improve the routine is easy. Use a StringBuilder. That would make the routine run around a 100000 times faster.
As an interresting observation in optimization, one can speed up the routine somewhat by using a temporary string:
string content, line;
content = string.Empty;
line = string.Empty;
for (int x = 0; x < Data.senderdata.Length; x++) {
if (x % 16 == 0) {
content += line;
line = String.Format("\n{0:X5}: ", (x+1));
}
line += String.Format("{0:X2}", Data.senderdata[x]);
if ((x + 1) % 2 == 0) line += " ";
}
content += line;
This would redude the number of lengthy concatenations from 1.5625 per iteration to 0.0625, reducing the execution time by 96%. Not nearly as effective as using a StringBuilder, but somewhat impressive eventhough...
---
b { font-weight: normal; }
-- modified at 11:27 Tuesday 6th June, 2006
|
|
|
|
|
I need leave my textBox control only if I press three times the Tab key. I use this:
<br />
private void KKEditControl_Leave(object sender, EventArgs e)<br />
{<br />
this.Focus();<br />
}<br />
but it keeps focus in my textBox all the time. Please help me...
|
|
|
|
|
You need to count how much times he leaves.
try this:
<br />
int NumLeaves = 1;<br />
private void KKEditControl_Leave(object sender, EventArgs e)<br />
{<br />
if (NumLeaves%3 != 0)<br />
this.Focus();<br />
NumLeaves++;<br />
}<br />
This should work.
|
|
|
|
|
I tried to count but in different way - it doesn`t work.
Your way works great!
Thanks a lot!
|
|
|
|
|
i get a exception when i show a form
the exception is the "object is currently used elsewhere :
i dont get these kind of exception when i call a form by creating an object
what is the reason
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
